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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect 
of ETSI standards", which is available free of charge from the ETSI Secretariat. Latest updates are available on the 
ETSI Web server (http://www.etsi.org/ipr). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in SR 000 314 (or the updates on the ETSI Web server) 
which are, or may be, or may become, essential to the present document. 



Foreword 



This Technical Specification (TS) has been produced by the Special Mobile Group (SMG). 

The present document defines the interface between the Subscriber Identity Module (SIM) and the Mobile Equipment 
(ME) within the digital cellular telecommunications system. 

The contents of the present document are subject to continuing work within SMG and may change following formal 
SMG approval. Should SMG modify the contents of the present document it will then be republished by ETSI with an 
identifying change of release date and an increase in version number as follows: 

Version 7.x.y 

where: 

7 indicates GSM Release 1998 of Phase 2+ 

X the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, 
etc. 

y the third digit is incremented when editorial only changes have been incorporated in the specification. 
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Scope 



The present document defines the interface between the Subscriber Identity Module (SIM) and the Mobile Equipment 
(ME) for use during the network operation phase of GSM as well as those aspects of the internal organization of the 
SIM which are related to the network operation phase. This is to ensure interoperability between a SIM and an ME 
independently of the respective manufacturers and operators. The concept of a split of the Mobile Station (MS) into 
these elements as well as the distinction between the GSM network operation phase, which is also called GSM 
operations, and the administrative management phase are described in the GSM 02.17 [6]. 

The present document defines: 

the requirements for the physical characteristics of the SIM, the electrical signals and the transmission protocols; 
the model which shall be used as a basis for the design of the logical structure of the SIM; 
the security features; 
the interface functions; 
- the commands; 

the contents of the files required for the GSM application; 
the application protocol. 

Unless otherwise stated, references to GSM also apply to DCS 1800 and PCS 1900. 

The present document does not specify any aspects related to the administrative management phase. Any internal 
technical reallocation of either the SIM or the ME are only specified where these reflect over the interface. It does not 
specify any of the security algorithms which may be used. 

The present document defines the SIM/ME interface for GSM Phase 2. While all attempts have been made to maintain 
phase compatibility, any issues that specifically relate to Phase 1 should be referenced from within the relevant Phase 1 
specification. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

• A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same 
number. 

• For this Release 1998 document, references to GSM documents are for Release 1998 versions (version 7.x.y). 

[1] GSM 01.02: "Digital cellular telecommunications system (Phase 2+); General description of a 

GSM Public Land Mobile Network (PLMN)". 

[2] GSM 01.04: "Digital cellular telecommunications system (Phase 2+); Abbreviations and 

acronyms". 

[3] GSM 02.07: "Digital cellular telecommunications system (Phase 2+); Mobile Stations (MS) 

features". 

[4] GSM 02.09: "Digital cellular telecommunications system (Phase 2+); Security aspects". 

[5] GSM 02.11: "Digital cellular telecommunications system (Phase 2h-); Service accessibility". 

[6] GSM 02. 17: "Digital cellular telecommunications system (Phase 2+); Subscriber Identity Modules 

(SIM) Functional characteristics". 



ETSI 



(GSM 11.11 version 7.3.0 Release 1998) 



10 



ETSI TS 100 977 V7.3.0 (1999-07) 



[7] 

[8] 

[9] 

[10] 

[11] 

[12] 

[13] 

[14] 

[15] 

[16] 

[17] 

[18] 
[19] 
[20] 

[21] 
[22] 
[23] 

[24] 

[25] 

[26] 

[27] 

[28] 



GSM 02.24: "Digital cellular telecommunications system (Phase 2+) 
Advice Information (CAl)". 

GSM 02.30: "Digital cellular telecommunications system (Phase 2+) 
(MMl) of the Mobile Station (MS)". 

GSM 02.86: "Digital cellular telecommunications system (Phase 2+) 
Supplementary Services - Stage 1". 

GSM 03.03: "Digital cellular telecommunications system (Phase 2+) 
identification". 

GSM 03.20: "Digital cellular telecommunications system (Phase 2+) 
functions". 

GSM 03.38: "Digital cellular telecommunications system (Phase 2+) 
language-specific information". 

GSM 03.40: "Digital cellular telecommunications system (Phase 2+) 
Short Message Service (SMS) Point-to-Point (PP)". 

GSM 03.41: "Digital cellular telecommunications system (Phase 2+) 
Short Message Service Cell Broadcast (SMSCB)". 

GSM 04.08: "Digital cellular telecommunications system (Phase 2+) 
3 specification". 

GSM 04.1 1: "Digital cellular telecommunications system (Phase 2+) 
Message Service (SMS) support on mobile radio interface". 



Description of Charge 
Man-Machine Interface 
Advice of charge (AoC) 
Numbering, addressing and 
Security related network 
Alphabets and 
Technical realization of the 
Technical realization of 
Mobile radio interface layer 
Point-to-Point (PP) Short 
Interworking aspects of the 



GSM 09.91: "Digital cellular telecommunications system (Phase 2+) 

Subscriber Identity Module - Mobile Equipment (SIM - ME) interface between Phase 1 and 

Phase 2". 

CCITT Recommendation E.118: "The international telecommunication charge card". 

CCITT Recommendation E.164: "Numbering plan for the ISDN era". 

CCITT Recommendation T.50: "International Alphabet No. 5". (ISO 646: 1983, "Information 
processing - ISO 7-bits coded characters set for information interchange".) 

ISO/lEC 7810 (1995): "Identification cards - Physical characteristics". 

ISO/lEC 7811-1 (1995): "Identification cards - Recording technique - Part 1: Embossing". 

ISO/IEC 781 1-3 (1995): "Identification cards - Recording technique - Part 3: Location of 
embossed characters on lD-1 cards". 

ISO/IEC 7816-1 (1987): "Identification cards - Integrated circuit(s) cards with contacts. Part 1: 
Physical characteristics". 

ISO/IEC 7816-2 (1988): "Identification cards - Integrated circuit(s) cards with contacts. Part 2: 
Dimensions and locations of the contacts". 

ISO/IEC 7816-3 (1997): "Identification cards - Integrated circuit(s) cards with contacts. Part 3: 
Electronic signals and transmission protocols". 

GSM 11.14: "Digital cellular telecommunications system (Phase 2+); Specification of the SIM 
Application Toolkit for the Subscriber Identity Module - Mobile Equipment (SIM - ME) 
interface". 

GSM 11.12: "Digital cellular telecommunications system (Phase 2); Specification of the 3 Volt 
Subscriber Identity Module - Mobile Equipment (SIM - ME) interface". 



£75/ 



(GSM 11.11 version 7.3.0 Release 1 998) 1 1 ETSI TS 1 00 977 V7.3.0 (1 999-07) 

[29] GSM 02.22: "Digital cellular telecommunications system (Phase 2+); Personalization of GSM 

Mobile Equipment (ME) Mobile functionality specification" . 

[30] ISO 639 (1988): "Code for the representation of names of languages". 

[31] ISO/IEC 10646-1 (1993): "Information technology -- Universal Multiple-Octet Coded Character 

Set (UCS) - Part 1: Architecture and Basic Multilingual Plane". 

[32] GSM 03.60: "Digital cellular telecommunications system (Phase 2+); General Packet Radio 

Service (GPRS); Service description; Stage 2". 

[33] GSM 03.73: "Digital cellular telecommunications system (Phase 2+); Support of Localised Service 

Area (SoLSA); Service description; Stage 2". 

[34] GSM 11.19: "Digital cellular telecommunications system (Phase 2+); Specification of the Cordless 

Telephony System Subscriber Identity Module for both Fixed Part and Mobile Station". 



3 Definitions, abbreviations and symbols 

3.1 Definitions 

For the purposes of the present document, the following definitions apply. For further information and definitions refer 
to GSM 01.02 [1]. 

access conditions: A set of security attributes associated with a file. 

application: An application consists of a set of security mechanisms, files, data and protocols (excluding transmission 
protocols). 

application protocol: The set of procedures required by the application. 

card session: A link between the card and the external world starting with the ATR and ending with a subsequent reset 
or a deactivation of the card. 

current directory: The latest MF or DF selected. 

current EF: The latest EF selected. 

data field: Obsolete term for Elementary File. 

Dedicated File (DF): A file containing access conditions and, optionally. Elementary Files (EFs) or other Dedicated 
Files (DFs). 

directory: General term for MF and DF. 

Elementary File (EF): A file containing access conditions and data and no other files. 

file: A directory or an organized set of bytes or records in the SIM. 

file identifier: The 2 bytes which address a file in the SIM. 

GSM, DCS 1800 or PCS 1900 application: Set of security mechanisms, files, data and protocols required by GSM, 
DCS 1800 or PCS 1900. 

GSM session: That part of the card session dedicated to the GSM operation. 

IC card SIM: Obsolete term for ID-1 SIM. 

ID-1 SIM: The SIM having the format of an ID-1 card (see ISO 7816-1 [24]). 

Master File (MF): The unique mandatory file containing access conditions and optionally DFs and/or EFs. 

normal GSM operation: Relating to general, CHV related, GSM security related and subscription related procedures. 
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padding: One or more bits appended to a message in order to cause the message to contain the required number of bits 
or bytes. 

plug-in SIM: A Second format of SIM (specified in clause 4). 

proactive SIM: A SIM which is capable of issuing commands to the ME. Part of SIM Application Toolkit (see clause 
11). 

record: A string of bytes within an EF handled as a single entity (see clause 6). 

record number: The number which identifies a record within an EF. 

record pointer: The pointer which addresses one record in an EF. 

root directory: Obsolete term for Master File. 

SIM application toolkit procedures: Defined in GSM 1 1.14 [27]. 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply, in addition to those listed in 
GSM 01.04 [2]: 

A3 Algorithm 3, authentication algorithm; used for authenticating the subscriber 

A5 Algorithm 5, cipher algorithm; used for enciphering/deciphering data 

A8 Algorithm 8, cipher key generator; used to generate K,, 

A38 A single algorithm performing the functions of A3 and A8 

ACM Accumulated Call Meter 

ADN Abbreviated Dialling Number 

ADM Access condition to an EF which is under the control of the authority which creates this file 

ALW ALWays 

AoC Advice of Charge 

APDU Application Protocol Data Unit 

ATR Answer To Reset 

BCCH Broadcast Control CHannel 

BCD Binary Coded Decimal 

BDN Barred Dialling Number 

BTS Base Transmitter Station 

CB Cell Broadcast 

CBMI Cell Broadcast Message Identifier 

CCITT The International Telegraph and Telephone Consultative Committee (now also known as the ITU 

Telecommunications Standardization sector) 

CCP Capability/Configuration Parameter 

CHV Card Holder Verification information; access condition used by the SIM for the verification of the 

identity of the user 

CLA CLASS 

CNL Co-operative Network List 

CTS Cordless Telephony System 

DCK De-personalization Control Keys 

DCS Digital Cellular System 

DF Dedicated File (abbreviation formerly used for Data Field) 

DTMF Dual Tone Multiple Frequency 

ECC Emergency Call Code 

EF Elementary File 

ETSI European Telecommunications Standards Institute 

eMLPP enhanced Multi-Level Precedence and Pre-emption Service 

etu elementary time unit 

FDN Fixed Dialling Number 

GSM Global System for Mobile communications 

HPLMN Home PLMN 

IC Integrated Circuit 
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ICC Integrated Circuit(s) Card 

ID IDentifier 

lEC International Electro technical Commission 

IMSI International Mobile Subscriber Identity 

ISO International Organization for Standardization 

Kc Cryptographic key; used by the cipher A5 

Ki Subscriber authentication key; the cryptographic key used by the authentication algorithm, A3, and 

cipher key generator, A8 

LAI Location Area Information; information indicating a cell or a set of cells 

Igth The (specific) length of a data unit 

LND Last Number Dialled 

LSA Localised Service Area 

LSA ID Localised Service Area Identity 

LSB Least Significant Bit 

MCC Mobile Country Code 

ME Mobile Equipment 

MF Master File 

MMI Man Machine Interface 

MNC Mobile Network Code 

MS Mobile Station 

MSISDN Mobile Station international ISDN number 

MSB Most Significant Bit 

NET NETwork 

NEV NEVer 

NPI Numbering Plan Identifier 

PIN/PIN2 Personal Identification Number / Personal Identification Number 2 (obsolete terms for CHVl and 

CHV2, respectively) 

PLMN Public Land Mobile Network 

PPS Protocol and Parameter Select (response to the ATR) 

PUK/PUK2 PIN Unblocking Key / PIN2 Unblocking Key (obsolete terms for UNBLOCK CHVl and 

UNBLOCK CHV2, respectively) 

RAND A RANDom challenge issued by the network 

RFU Reserved for Future Use 

SDN Service Dialling Number 

SIM Subscriber Identity Module 

SMS Short Message Service 

SoLS A Support of Localised Service Area 

SRES Signed RESponse calculated by a SIM 

SSC Supplementary Service Control string 

SW1/SW2 Status Word 1 / Status Word 2 

TMSI Temporary Mobile Subscriber Identity 

TON Type Of Number 

TP Transfer layer Protocol 

TPDU Transfer Protocol Data Unit 

TS Technical Specification 
UNBLOCK CHVl/2 value to unblock CHV1/CHV2 

VBS Voice Broadcast Service 

VGCS Voice Group Call Service 

VPLMN Visited PLMN 



3.3 Symbols 



Vcc Supply voltage 

Vpp Programming voltage 

'0' to '9' and 'A' to 'F' The sixteen hexadecimal digits 
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4 Physical characteristics 

Two physical types of SIM are specified. These are the 'TD-1 SIM" and the "Plug-in SIM". 

The physical characteristics of both types of SIM shall be in accordance with ISO 7816-1,2 [24, 25] unless otherwise 
specified. The following additional requirements shall be applied to ensure proper operation in the GSM environment. 

4.1 Format and layout 

The information on the exterior of either SIM should include at least the individual account identifier and the check digit 
of the IC Card Identification (see clause 10, EFj(-;(2jj5). 

4.1.1 ID-1 SIM 

Format and layout of the ID-1 SIM shall be in accordance with ISO 7816-1,2 [24, 25]. 

The card shall have a polarization mark (see GSM 02.07 [3]) which indicates how the user should insert the card into the 
ME. 

The ME shall accept embossed ID-1 cards. The embossing shall be in accordance with ISO/IEC 781 1 [22, 23]. The 
contacts of the ID-1 SIM shall be located on the front (embossed face, see ISO/IEC 7810 [21]) of the card. 

NOTE: Card warpage and tolerances are now specified for embossed cards in ISO/IEC 7810 [21]. 

4.1.2 Plug-in SIM 

The Plug-in SIM has a width of 25 mm, a height of 15 mm, a thickness the same as an ID-1 SIM and a feature for 
orientation. See figure A. 1 in normative annex A for details of the dimensions of the card and the dimensions and 
location of the contacts. 

Annexes A.l and A.2 of ISO 7816-1 [24] do not apply to the Plug-in SIM. 

Annex A of ISO 7816-2 [25] applies with the location of the reference points adapted to the smaller size. The three 
reference points PI, P2 and P3 measure 7,5 mm, 3,3 mm and 20,8 mm, respectively, from 0. The values in table A.l of 
ISO 7816-2 [25] are replaced by the corresponding values of figure A.l. 

4.2 Temperature range for card operation 

The temperature range for full operational use shall be between -25°C and H-70°C with occasional peaks of up to H-85°C. 
"Occasional" means not more than 4 hours each time and not over 100 times during the life time of the card. 

4.3 Contacts 

4.3.1 Provision of contacts 

ME: Contacting elements in the ME in positions C4 and C8 are optional, and are not used in the GSM 

application. They shall present a high impedance to the SIM card in the GSM application. If it is 
determined that the SIM is a multi-application ICC, then these contacts may be used. Contact C6 need not 
be provided for Plug-in SIMs. 

SIM: Contacts C4 and C8 need not be provided by the SIM, but if they are provided, then they shall not be 

connected internally in the SIM if the SIM only contains the GSM application. Contact C6 shall not be 
bonded in the SIM for any function other than supplying Vpp. 
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4.3.2 Activation and deactivation 

The ME shall connect, activate and deactivate the SIM in accordance with the Operating Procedures specified in 
ISO/IEC 7816-3 [26]. 

For any voltage level, monitored during the activation sequence, or during the deactivation sequence following soft 
power-down, the order of the contact activation/deactivation shall be respected. 

NOTE 1: Soft Power switching is defined in GSM 02.07 [3]. 

NOTE 2: It is recommended that whenever possible the deactivation sequence defined in ISO/IEC 7816-3 [26] 
should be followed by the ME on all occasions when the ME is powered down. 

If the SIM clock is already stopped and is not restarted, the ME is allowed to deactivate all the contacts in any order, 
provided that all signals reach low level before Vcc leaves high level. If the SIM clock is already stopped and is 
restarted before the deactivation sequence, then the deactivation sequence specified in ISO/IEC 7816-3 [26] subclause 
5.4 shall be followed. 

When Vpp is connected to Vcc, as allowed by GSM (see clause 5), then Vpp will be activated and deactivated with Vcc, 
at the time of the Vcc activation/deactivation, as given in the sequences of ISO/IEC 7816-3 [26] subclauses 5.2 and 5.4. 

Vcc is powered when it has a value between 4,5 V and 5,5 V. 

4.3.3 Inactive contacts 

The voltages on contacts CI, C2, C3, C6 and C7 of the ME shall be between and + 0,4 volts referenced to ground (C5) 
when the ME is switched off with the power source connected to the ME. The measurement equipment shall have a 
resistance of 50 kohms when measuring the voltage on C2, C3, C6 and C7. The resistance shall be 10 kohms when 
measuring the voltage on CI. 



4.3.4 Contact pressure 

The contact pressure shall be large enough to ensure reliable and continuous contact (e.g. to overcome oxidisation and to 
prevent interruption caused by vibration). The radius of any curvature of the contacting elements shall be greater than or 
equal to 0,8 mm over the contact area. 

Under no circumstances may a contact force be greater than 0,5 N per contact. 

Care shall be taken to avoid undue point pressure to the area of the SIM opposite to the contact area. Otherwise this may 
damage the components within the SIM. 

4.4 Precedence 

See GSM 02.17 [6] for precedence. 

4.5 Static Protection 

Considering that the SIM is a CMOS device, the ME manufacturer shall take adequate precautions (in addition to the 
protection diodes inherent in the SIM) to safeguard the ME, SIM and SIM/ME interface from static discharges at all 
times, and particularly during SIM insertion into the ME. 



5 Electronic signals and transmission protocols 

Electronic signals and transmission protocols shall be in accordance with ISO/IEC 7816-3 [26] unless specified 
otherwise. The following additional requirements shall be applied to ensure proper operation in the GSM environment. 

The choice of the transmission protocol(s), to be used to communicate between the SIM and the ME, shall at least 
include that specified and denoted by T=0 in ISO/IEC 7816-3 [26]. 
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The values given in the tables hereafter are derived from ISO/IEC 7816-3 [26], subclause 4.3 with the following 
considerations: 

^OH '^^'^ ^OL always refer to the device (ME or SIM) which is driving the interface. Vjj^ and Vj^ always refer to 
the device (ME or SIM) which is operating as a receiver on the interface. 

This convention is different to the one used in ISO/IEC 7816-3 [26], which specifically defines an ICC for which 
its current conventions apply. The following clauses define the specific core requirements for the SIM, which 
provide also the basis for Type Approval. For each state (Vqjj, Vjj^, Vj^ and Vq^) a positive current is defined as 
flowing out of the entity (ME or SIM) in that state. 

5.1 Supply voltage Vcc (contact C1 ) 

The SIM shall be operated within the following limits: 

Table 1 : Electrical characteristics of Vcc under normal operating conditions 



Symbol 


Minimum 


Maximum 


Unit 


Vcc 


4,5 


5,5 


V 


Ice 




10 


mA 



The current consumption of the SIM shall not exceed the value given in table 1 during any state (including activation 
and deactivation as defined in subclause 4.3.2). 

When the SIM is in idle state (see below) the current consumption of the card shall not exceed 200 |i A at 1 MHz and 
25°C. If clock stop mode is allowed, then the current consumption shall also not exceed 200 |iA while the clock is 
stopped. 

The ME shall source the maximum current requirements defined above. It shall also be able to counteract spikes in the 
current consumption of the card up to a maximum charge of 40 nAs with no more than 400 ns duration and an amplitude 
of at most 200 mA, ensuring that the supply voltage stays in the specified range. 

NOTE: A possible solution would be to place a capacitor (e.g. 100 nF, ceramic) as close as possible to the 
contacting elements. 



5.2 Reset (RST) (contact C2) 



The ME shall operate the SIM within the following limits: 

Table 2: Electrical characteristics of RST under normal operating conditions 



Symbol 


Conditions 


Minimum 


Maximum 


VOH 


lOHmax = +20 MA 


Vcc-0,7 


Vcc (note) 


Vol 


l0Lmax = -200 mA 


OV (note) 


0,6 V 


tRtp 


Cout = Cin = 30pF 




400 MS 


NOTE: To allow for overshoot the voltage on RST shall remain between 
-0,3 V and Vcc+0,3 V during dynamic operation. 



5.3 Programming voltage Vpp (contact C6) 

SIMs shall not require any programming voltage on Vpp. The ME need not provide contact C6. If the ME provides 
contact C6, then, in the case of the ID-1 SIM the same voltage shall be supplied on Vpp as on Vcc, while in the case of 
Plug-in SIMs the ME need not provide any voltage on C6. Contact C6 may be connected to Vcc in any ME but shall not 
be connected to ground. 
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5.4 Clock CLK (contact C3) 



The SIM shall support 1 to 5 MHz. The clock shall be supplied by the ME. No "internal clock" SIMs shall be used. 

If a frequency of 13/4 MHz is needed by the SIM to run the authentication procedure in the allotted time (see 
GSM 03.20 [11]), or to process an ENVELOPE command used for SIM Data Download, bit 2 of byte 1 in the file 
characteristics shall be set to 1. Otherwise a minimum frequency of 13/8 MHz may be used. 

The duty cycle shall be between 40 % and 60 % of the period during stable operation. 

The ME shall operate the SIM within the following limits: 

Table 3: Electrical characteristics of CLK under normal operating conditions 



Symbol 


Conditions 


IVIinimum 


Maximum 


VOH 


lOHmax = +20 mA 


0,7xVcc 


Vcc (note) 


Vol 


lOLmax = "200 nA 


V (note) 


0,5 V 


tRtp 


Cout = C|n = 30 pF 




9 % of period with a maximum of 
0,5 MS 


NOTE: To allow for overshoot the voltage on CLK shall remain between -0,3 V and 
Vcc+0,3 V during dynamic operation. 



5.5 I/O (contact C7) 

Table 4 defines the electrical characteristics of the I/O (contact C7). The values given in the table have the effect of 
defining the values of the pull-up resistor in the ME and the impedances of the drivers and receivers in the ME and SIM. 

Table 4: Electrical characteristics of I/O under normal operating conditions 



Symbol 


Conditions 


Minimum 


Maximum 


V|H 


llHmax = ± 20 mA (note 2) 


0,7xVcc 


Vcc-i-0,3 V 


V|L 


l|Lmax = +1 mA 


-0,3 V 


0,8 V 


VoH(notel) 


lOHmax = + 20mA 


3,8 V 


Vcc (note 3) 


Vol 


'OLmax = "I ^A 


V (note 3) 


0,4 V 


tptp 


Cout = Cin = 30pF 




1 lis 


NOTE 1 : It is assumed that a pull-up resistor is used in the interface device (recommended 
value: 20 kohms). 


NOTE 2: During static conditions (idle state) only the positive value can apply. Under 

dynamic operating conditions (transmission) short term voltage spikes on the I/O 
line may cause a current reversal. 


NOTE 3: To allow for overshoot the voltage on I/O shall remain between -0,3 V and 
Vcc-h0,3 V during dynamic operation. 



5.6 States 

There are two states for the SIM while the power supply is on: 

The SIM is in operating state when it executes a command. This state also includes transmission from and to the 

ME. 

The SIM is in idle state at any other time. It shall retain all pertinent data during this state. 

The SIM may support a clock stop mode. The clock shall only be switched off subject to the conditions specified in the 
file characteristics (see clause 9). 
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Clock stop mode. An ME of Phase 2 or later shall wait at least 1 860 clock cycles after having received the last 
character, including the guard time (2 etu), of the response before it switches off the clock (if it is allowed to do so). It 
shall wait at least 744 clock cycles before it sends the first command after having started the clock. 

To achieve phase compatibility, the following procedure shall be adhered to: 

A SIM of Phase 2 or later shall always send the status information "normal ending of the command" after the successful 
interpretation of the command SLEEP received from a Phase 1 ME. An ME of Phase 2 or later shall not send a SLEEP 
command. 

A Phase 1 ME shall wait at least 744 clock cycles after having received the compulsory acknowledgement SWl SW2 of 
the SLEEP command before it switches off the clock (if it is allowed to do so). It shall wait at least 744 clock cycles 
before it sends the first command after having started the clock. 

5.7 Baudrate 

The initial baudrate (during ATR) shall be: (clock frequency)/372. Subsequent baudrate shall be: (clock frequency)/372 
unless the PPS procedure has been successfully performed. In that case the negotiated baudrate shall be applied 
according to subclause 5.8.2. 



5.8 Answer To Reset (ATR) 



The ATR is information presented by the SIM to the ME at the beginning of the card session and gives operational 
requirements. 

5.8.1 Structure and contents 

The following table gives an explanation of the characters specified in ISO/IEC 7816-3 [26] and the requirements for 
their use in GSM. The answer to reset consists of at most 33 characters. The ME shall be able to receive interface 
characters for transmission protocols other than T=0, historical characters and a check byte, even if only T=0 is used by 
the ME. 
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Table5:ATR 



Character 


Contents 


sent by 
the card 


a) evaluation by the ME 
b) reaction by the ME 


1. Initial character 
TS 


coding convention for all 
subsequent characters 
(direct or inverse 
convention) 


always 


a) always 

b) using appropriate convention 


2. Format 
character 

TO 


subsequent interface 
characters, number of 
historical characters 


always 


a) always 

b) identifying the subsequent 
characters accordingly 


3. Interface 
character 
(global) 

TA1 


parameters to calculate the 
work etu 


optional 


a) always if present 

b) if TA1 is not '1 1 ' or '01 ', PPS procedure 
shall be used (see subclause 5.8.2) 


4. Interface 
character 
(global) 

TB1 


parameters to calculate the 
programming voltage and 
current 


optional 


a) always if present 

b) if PI1 is not 0, then reject the SIM (in 
accordance with subclause 5.10) 


5. Interface 
character 
(global) 

TC1 


parameters to calculate the 
extra guardtime requested 
by the card; no extra 
guardtime is used to send 
characters from the card to 
the ME 


optional 


a) always if present 

b) if TCI is neither nor 255, then reject the 
SIM (in accordance with subclause 5.10); see 
the note after the table 


6. Interface 
character 

TD1 


protocol type; indicator for 
the presence of interface 
characters, specifying rules 
to be used for transmissions 
with the given protocol type 


always, if 
T=15 

indicated in 
TDi (i>1) 


a) always if present 

b) identifying the subsequent characters 
accordingly 


7. Interface 
character 
(specific) 

TA2 


not used for protocol T=0 


optional 


a) optional 

b) 


8. Interface 
character 
(global) 

TB2 


parameter to calculate the 
programming voltage 


never 


the allowed value of TBI above defines that an 
external programming voltage is not applicable 


9. Interface 
character 
(specific) 

TC2 


parameters to calculate the 
work waiting time 


optional 


a) always if present 

b) using the work waiting time accordingly 


10. Interface 
character 

TDi 
(i>1) 


protocol type; indicator for 
the presence of interface 
characters, specifying rules 
to be used for transmissions 
with the given protocol type 


optional 


a) always if present 

b) identifying the subsequent characters 
accordingly 






(continued) 
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Table 5 (concluded): ATR 



Character 


Contents 


sent by 
the card 


a) evaluation by the ME 
b) reaction by the ME 


11. Interface 
character 

TAi, TBI, TCI 
(i>2) 


characters which contain 
interface characters for 
other transmission 
protocols. If TD(i-l) 
indicates T=15, TAi is 
interpreted as global 
interface character 


Always if 

TD(i-l) 

indicates 

T=15. 

Optional 

otherwise. 


a) always 

b) If T=1 5 is indicated in TD{i-1 ), TAi 
Indicates: 

XI clock stop indicator {b8 to b7) 
Ul class indicator (b6 to b1) 


12. Historical 
characters 

T1,...,TK 


contents not specified in 
ISO/IEC 


optional 


a) optional 

b) 


13. Check 
character 

TCK 


check byte (exclusive 
-ORing) 


not sent if 
only T=0 is 
indicated in 
the ATR. If 
T=0 and 
T=15 are 
present and 
in all other 
cases, TCK 
shall be sent 


a) optional 

b) 


NOTE: According to ISO/IEC 7816-3:1997 [26], N=255 indicates that the minimum delay is 12 etu for the 
asynchronous half-duplex character transmission protocol. 

If '01' is indicated in TAI , PPS should be supported by the SIIVI to allow backward compatibility with existing IVIEs. 
For the interpretation of '01', see ISO/IEC 7816-3 [26]. 



5.8.2 PPS procedure 



Specifically related to the present document the PPS procedure according to ISO/IEC 7816-3 [26], clause 7, is applied, 
only if TAI is not equal to '11' or '01', as follows: 

a) for MEs only supporting default speed (F=372, D=l) 

Reset > 

ATR 



ME 



SIM 



TAI not = '11 'or '01' 



PPSS = 


'FF' 


PPSO = 


'00' 


PCK = 


'FF' 



PPS Response 



PPS Request 



PPSS = 


'FF' 


PPSO = 


'00' 


PCK = 


'FF' 



Figure 1 : PPS procedure 

PPS Request and PPS Response consist of the three (3) characters PPSS, PPSO and PCK of which PPSS is sent first. 
After this procedure the protocol T=0 and the parameters F=372, D=l and N=0 shall be used. 
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b) for MEs only supporting enhanced speed (F=512, D=8) 
Reset 



ME 



ATR- 



PPSS = 


'FF' 


PPSO = 


'10' 


PPS1 = 


'94' 


PCK = 


'7B' 



PPS Response 



PPS Request 



SIM 



TA1 = '94' 



PPSS = 


'FF' 


PPSO = 


'10' 


PPS1 = 


'94' 


PCK = 


'7B' 



Figure 2: PPS procedure requesting enhianced speed values (F=512, D=8, see clause 5.8.3) 

PPS Request and PPS Response consist of the four (4) characters PPSS, PPSO, PPSl and PCK, of which PPSS is sent 
first. 

After this procedure, the protocol T=0 and the parameters F=512, D=8 and N=0 shall be used. 

5.8.3 Speed enhancement 

If speed enhancement is implemented, the ME and the SIM shall at least support F=512 and D=8 in addition to F=372 
and D=l. However, other values may also be supported. If the ME requests PPS using values other than those above 
then the PPS procedure shall be initiated accordingly. 

The SIM shall support the default value (F=372 and D=l). If the speed enhancement is supported by the SIM it is 
mandatory that F=512 and D=8 is supported. However, the value in TAl may even indicate a faster speed (F=512 and 
D=16). The SIM may also support other values between the default value (F=372 and D=l) and the values indicated in 
TAl. The SIM shall offer the negotiable mode, to ensure backwards compatibility with existing MEs. In the negotiable 
mode the SIM will use default values even if other parameters are offered in the ATR if the PPS procedure is not 
initiated. 

The ME shall support the default value (F=372 and D=l). If the speed enhancement is supported in the ME it is 
mandatory to support F=512 and D=8. The ME may additionally support other values. 

If the SIM does not answer the PPS request within the initial waiting time the ME shall reset the SIM. After two failed 
PPS attempts using F=512 and D=8 or values indicated in TAl, (no PPS response from the SIM) the ME shall initiate 
PPS procedure using default values. If this also fails (no PPS response from the SIM) the ME may proceed using default 
values without requesting PPS. 

If the SIM does not support the values requested by the ME, the SIM shall respond to the PPS request indicating the use 
of default values. 

5.9 Bit/character duration and sampling time 

The bit/character duration and sampling time specified in ISO/IEC 7816-3 [26], subclause 6.3.2 are valid for all 
communications . 



5.10 Error handling 



Following receipt of an ATR, which is not in accordance with this specification, e.g. because of forbidden ATR 
characters or too few bytes being transmitted, the ME shall perform a Reset. The ME shall not reject the SIM until at 
least three consecutive wrong ATRs are received. 

During the transmission of the ATR and the protocol type selection, the error detection and character repetition 
procedure specified in ISO/IEC 7816-3 [26], subclause 6.3.3, is optional for the ME. For the subsequent transmission on 
the basis of T=0 this procedure is mandatory for the ME. 
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For the SIM the error detection and character repetition procedure is mandatory for all communications. 



Logical Model 



This clause describes the logical structure for a SIM, the code associated with it, and the structure of files used. 



6.1 General description 



Figure 3 shows the general structural relationships which may exist between files. The files are organized in a 
hierarchical structure and are of one of three types as defined below. These files may be either administrative or 
application specific. The operating system handles the access to the data stored in different files. 
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Figure 3: Organization of memory 

Files are composed of a header, which is internally managed by the SIM, and optionally a body part. The information of 
the header is related to the structure and attributes of the file and may be obtained by using the commands GET 
RESPONSE or STATUS. This information is fixed during the administrative phase. The body part contains the data of 
the file. 



6.2 



File identifier 



A file ID is used to address or identify each specific file. The file ID consists of two bytes and shall be coded in 
hexadecimal notation. They are specified in clause 10. 

The first byte identifies the type of file, and for GSM is: 

- '3F': Master File; 

- 7F' : r ' level Dedicated File ; 

- '5F: 2"'' level Dedicated File; 

'2F': Elementary File under the Master File; 

'6F': Elementary File under a 1** level Dedicated File; 

'4F': Elementary File under 2" level Dedicated File. 
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File IDs shall be subject to the following conditions: 

the file ID shall be assigned at the time of creation of the file concerned; 

no two files under the same parent shall have the same ID; 

a child and any parent, either immediate or remote in the hierarchy, e.g. grandparent, shall never have the 

same file ID. 

In this way each file is uniquely identified. 

6.3 Dedicated files 

A Dedicated File (DF) is a functional grouping of files consisting of itself and all those files which contain this DF in 
their parental hierarchy (that is to say it consists of the DF and its complete "subtree"). A DF "consists" only of a header 
part. 

Four r' level DFs are defined in this specification: 

DFQ3]y[ which contains the applications for both GSM and/or DCS 1800; 

DFj542 which contains the applications for IS-41 as specified by ANSI TlPl; 

DFjgLECOM which contains telecom service features; 

DFpp.cTs which contains the applications for the CTS fixed part (see GSM 11.19 [34]). 

All four files are immediate children of the Master File (MF) and may coexist on a multi-application card. 

2"'' level DFs are defined in this specification under DFggjyj. 

All 2"'' level DFs are immediate children of the DFqsm and may coexist on a multi-application card. 



6.4 Elementary files 



An Elementary File (EF) is composed of a header and a body part. The following three structures of an EF are used by 
GSM. 



6.4.1 Transparent EF 




An EF with a transparent structure consists of a sequence of bytes. When reading or updating, the sequence of bytes to 
be acted upon is referenced by a relative address (offset), which indicates the start position (in bytes), and the number of 
bytes to be read or updated. The first byte of a transparent EF has the relative address '00 00'. The total data length of 
the body of the EF is indicated in the header of the EF. 

Header 
Body 



NOTE: This structure was previously referred to as "binary" in GSM. 

Figure 4: Structure of a transparent EF 

6.4.2 Linear fixed EF 

An EF with linear fixed structure consists of a sequence of records all having the same (fixed) length. The first record is 
record number 1 . The length of a record as well as this value multiplied by the number of records are indicated in the 
header of the EF. 
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Header 
Body 





Record 1 


Record 2 




Record n 



Figure 5: Structure of a linear fixed file 

There are several methods to access records within an EF of this type: 

absolutely using the record number; 

when the record pointer is not set it shall be possible to perform an action on the first or the last record by 
using the NEXT or PREVIOUS mode; 

when the record pointer is set it shall be possible to perform an action on this record, the next record (unless 
the record pointer is set to the last record) or the previous record (unless the record pointer is set to the first 
record); 

- by identifying a record using pattern seek starting: 

forwards from the beginning of the file; 

forwards from the record following the one at which the record pointer is set (unless the record pointer is 
set to the last record); 

- backwards from the end of the file; 

- backwards from the record preceding the one at which the record pointer is set (unless the record pointer 
is set to the first record). 

If an action following selection of a record is aborted, then the record pointer shall remain set at the record at which it 
was set prior to the action. 

NOTE 1: It is not possible, at present, to have more than 255 records in a file of this type, and each record cannot be 
greater than 255 bytes. 

NOTE 2: This structure was previously referred to as "formatted" in GSM. 

6.4.3 Cyclic EF 

Cyclic files are used for storing records in chronological order. When all records have been used for storage, then the 
next storage of data shall overwrite the oldest information. 

An EF with a cyclic structure consists of a fixed number of records with the same (fixed) length. In this file structure 
there is a link between the last record (n) and the first record. When the record pointer is set to the last record n, then the 
next record is record 1. Similarly, when the record pointer is set to record 1, then the previous record is record n. The 
last updated record containing the newest data is record number 1, and the oldest data is held in record number n. 

Header 
Body 





Record 1 


Record 2 




Record n 



Figure 6: Structure of a cyclic file 

For update operations only PREVIOUS record shall be used. For reading operations, the methods of addressing are 
Next, Previous, Current and Record Number. 
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After selection of a cyclic file (for either operation), the record pointer shall address the record updated or increased last. 
If an action following selection of a record is aborted, then the record pointer shall remain set at the record at which it 
was set prior to the action. 

NOTE: It is not possible, at present, to have more than 255 records in a file of this type, and each record cannot be 
greater than 255 bytes. 



6.5 Methods for selecting a file 



After the Answer To Reset (ATR), the Master File (MF) is implicitly selected and becomes the Current Directory. Each 
file may then be selected by using the SELECT function in accordance with the following rules. 

Selecting a DF or the MF sets the Current Directory. After such a selection there is no current EF. Selecting an EF sets 
the current EF and the Current Directory remains the DF or MF which is the parent of this EF. The current EF is always 
a child of the Current Directory. 

Any application specific command shall only be operable if it is specific to the Current Directory. 

The following files may be selected from the last selected file: 

any file which is an immediate child of the Current Directory; 

any DF which is an immediate child of the parent of the current DF; 

- the parent of the Current Directory; 
the current DF; 

- the MF. 

This means in particular that a DF shall be selected prior to the selection of any of its EFs. All selections are made using 
the file ID. 

The following figure gives the logical structure for the GSM application. GSM defines only two levels of DFs under the 
MF. 



MF 



EF1 





DF1 








EF2 


DF3 





DF2 



EFS 



EF4 



EFS 



Figure 7: Logical structure 



The following table gives the valid selections for GSM for the logical structure in figure 7. Reselection of the last 
selected file is also allowed but not shown. 
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Table 6: File selection 



Last selected file 


Valid Selections 


MF 


DF1, DF2, EF1 


DF1 


MF, DF2, DF3, EF2 


DF2 


MF, DF1, EF3, EF4 


DF3 


MF, DF1, EF5 


EF1 


MF, DF1, DF2 


EF2 


MF, DF1, DF2, DF3 


EF3 


MF, DF1, DF2, EF4 


EF5 


MF, DF1, DF3 



6.6 



Reservation of file IDs 



In addition to the identifiers used for the files specified in the present document, the following file IDs are reserved for 
use by GSM. 

Dedicated Files: 

administrative use: 

7F 4X', '5F1X', '5F2X' 
operational use: 

7F 10' (DFtelecom)^ '7F 20' (DFgsm), '7F 21' (DFdcsi80o)^ '7F 22' (DFis.41), 7F 23' (DFpp.cTs) (see 
GSM 11.19 [34]),and 7F 2X', where X ranges from '4' to 'F'. 
- reserved under 7F10': 
'5F50' (DFgraphics) 
reserved under 7F20': 

'5F30' (DFiridium), '5F31' (DFoiobaistJ, '5F32' (DF,co), '5F33' (DFACes), '5F3X', where X ranges from '4' to 

'F for other MS S. 

'5F40'(DFpcs-i9oo), '5F4Y' where Y ranges from '1' to 'F; 

'5F5X' where X ranges from '0' to 'F'; 

'5F60'(DFcTs)^ '5F6Y' where Y ranges from '1' to 'F'; 

'5F70' (DF|5qL|5^), '5F7Y' where Y ranges from '1' to 'F'; 

'5FYX' where Y ranges from '8' to 'F' and X from '0' to 'F'. 

Elementary files: 
administrative use: 

'6F XX' in the DFs '7F 4X'; '4F XX' in the DFs '5F IX', '5F2X' 

'6F IX' in the DFs '7F 10', '7F 20', '7F 21'; 

'4F IX' in all 2"'^ level DFs 

'2F or, '2F EX' in the MF '3F 00'; 
operational use: 

'6F 2X', '6F 3X', '6F 4X' in 7F 10' and 7F 2X'; 

'4F YX', where Y ranges from '2' to 'F' in all 2"'' level DFs. 

'2F IX' in the MF '3F 00'. 

In all the above, X ranges, unless otherwise stated, from '0' to 'F'. 



Security features 



The security aspects of GSM are described in the normative references GSM 02.09 [4] and GSM 03.20 [11]. This clause 
gives information related to security features supported by the SIM to enable the following: 

authentication of the subscriber identity to the network; 
data confidentiality over the radio interface; 
file access conditions. 
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7.1 Authentication and cipher key generation procedure 

This subclause describes the authentication mechanism and cipher key generation which are invoked by the network. For 
the specification of the corresponding procedures across the SIM/ME interface see clause 1 1 . 

The network sends a Random Number (RAND) to the MS. The ME passes the RAND to the SIM in the command RUN 
GSM ALGORITHM. The SIM returns the values SRES and Kc to the ME which are derived using the algorithms and 
processes given below. The ME sends SRES to the network. The network compares this value with the value of SRES 
which it calculates for itself. The comparison of these SRES values provides the authentication. The value Kc is used by 
the ME in any future enciphered communications with the network until the next invocation of this mechanism. 

A subscriber authentication key Ki is used in this procedure. This key Ki has a length of 128 bits and is stored within the 
SIM for use in the algorithms described below. 

7.2 Algorithms and processes 

The names and parameters of the algorithms supported by the SIM are defined in GSM 03.20 [11]. These are: 

Algorithm A3 to authenticate the MS to the network; 
Algorithm A8 to generate the encryption key. 

These algorithms may exist either discretely or combined (into A38) within the SIM. In either case the output on the 
SIM/ME interface is 12 bytes. The inputs to both A3 and A8, or A38, are Ki (128 bits) internally derived in the SIM, 
and RAND (128 bits) across the SIM/ME interface. The output is SRES (32 bits)/Kc (64 bits) the coding of which is 
defined in the command RUN GSM ALGORITHM in clause 9. 



7.3 



File access conditions 



Every file has its own specific access condition for each command. The relevant access condition of the last selected file 
shall be fulfilled before the requested action can take place. 

For each file: 

the access conditions for the commands READ and SEEK are identical; 

the access conditions for the commands SELECT and STATUS are ALWays. 

No file access conditions are currently assigned by GSM to the MF and the DFs. 

The access condition levels are defined in the following table: 

Table 7: Access condition level coding 



Level 


Access Condition 





ALWays 


1 


CHVl 


2 


CHV2 


3 


Reserved for GSM Future Use 


4 to 14 


ADM 


15 


NEVer 



The meaning of the file access conditions is as follows: 

ALWAYS: The action can be performed without any restriction; 

CHVl (card holder verification 1): The action shall only be possible if one of the following three conditions is 
fulfilled: 

a correct CHVl value has already been presented to the SIM during the current session; 
the CHVl enabled/disabled indicator is set to "disabled"; 

NOTE: Some Phase 1 and Phase 2 SIMs do not necessarily grant access when CHVl is "disabled" and 
"blocked". 
UNBLOCK CHVl has been successfully performed during the current session; 
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CHV2: The action shall only be possible if one of the following two conditions is fulfilled: 
a correct CHV2 value has already been presented to the SIM during the current session; 
UNBLOCK CHV2 has been successfully performed during the current session; 

ADM: Allocation of these levels and the respective requirements for their fulfilment are the responsibility of the 
appropriate administrative authority 

The definition of access condition ADM does not preclude the administrative authority from using ALW, CHVl, 
CHV2 and NEV if required. 

NEVER: The action cannot be performed over the SIM/ME interface. The SIM may perform the action 
internally. 

Condition levels are not hierarchical. For instance, correct presentation of CHV2 does not allow actions to be performed 
which require presentation of CHVl. A condition level which has been satisfied remains valid until the end of the GSM 
session as long as the corresponding secret code remains unblocked, i.e. after three consecutive wrong attempts, not 
necessarily in the same card session, the access rights previously granted by this secret code are lost immediately. A 
satisfied CHV condition level applies to both DFfjgj^ and DFYgLg(-^Q[^. 

The ME shall determine whether CHV2 is available by using the response to the STATUS command. If CHV2 is "not 
initialized" then CHV2 commands, e.g. VERIFY CHV2, shall not be executable. 



8 



Description of the functions 



This clause gives a functional description of the commands and their respective responses. Associated status conditions, 
error codes and their corresponding coding are specified in clause 9. 

It shall be mandatory for all cards complying with the present document to support all functions described in the present 
document. The command GET RESPONSE which is needed for the protocol T=0 is specified in clause 9. 

The following table lists the file types and structures together with the functions which may act on them during a GSM 
session. These are indicated by an asterisk (*). 

Table 8: Functions on files in GSIVI session 





File 


Function 


MF 


DF 


EF transparent 


EF linear fixed 


EF cyclic 


SELECT 


* 


* 


* 


* 


* 


STATUS 


* 


* 


* 


* 


* 


READ BINARY 






* 






UPDATE BINARY 






* 






READ RECORD 








* 


* 


UPDATE RECORD 








* 


* 


SEEK 








* 




INCREASE 










* 


INVALIDATE 






* 


* 


* 


REHABILITATE 






* 


* 


* 



8.1 



SELECT 



This function selects a file according to the methods described in clause 6. After a successful selection the record pointer 
in a linear fixed file is undefined. The record pointer in a cyclic file shall address the last record which has been updated 
or increased. 

Input: 

- file ID. 

Output: 

if the selected file is the MF or a DF: 

file ID, total memory space available, CHV enabled/disabled indicator, CHV status and other GSM specific 

data; 
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if the selected file is an EF: 

file ID, file size, access conditions, invalidated/not invalidated indicator, structure of EF and length of the 
records in case of linear fixed structure or cyclic structure. 

8.2 STATUS 

This function returns information concerning the current directory. A current EF is not affected by the STATUS 
function. It is also used to give an opportunity for a pro-active SIM to indicate that the SIM wants to issue a SIM 
Application Toolkit command to the ME. 

Input: 

none. 
Output: 

file ID, total memory space available, CHV enabled/disabled indicator, CHV status and other GSM specific data 

(identical to SELECT above). 

8.3 READ BINARY 

This function reads a string of bytes from the current transparent EF. This function shall only be performed if the READ 
access condition for this EF is satisfied. 

Input: 

- relative address and the length of the string. 
Output: 

- string of bytes. 

8.4 UPDATE BINARY 

This function updates the current transparent EF with a string of bytes. This function shall only be performed if the 
UPDATE access condition for this EF is satisfied. An update can be considered as a replacement of the string already 
present in the EF by the string given in the update command. 

Input: 

- relative address and the length of the string; 

- string of bytes. 
Output: 

none. 

8.5 READ RECORD 

This function reads one complete record in the current linear fixed or cyclic EF. The record to be read is described by 
the modes below. This function shall only be performed if the READ access condition for this EF is satisfied. The 
record pointer shall not be changed by an unsuccessful READ RECORD function. 

Four modes are defined: 

CURRENT: The current record is read. The record pointer is not affected. 

ABSOLUTE: The record given by the record number is read. The record pointer is not affected. 

NEXT: The record pointer is incremented before the READ RECORD function is performed and the pointed 
record is read. If the record pointer has not been previously set within the selected EF, then READ RECORD 
(next) shall read the first record and set the record pointer to this record. 

If the record pointer addresses the last record in a linear fixed EF, READ RECORD (next) shall not cause the 
record pointer to be changed, and no data shall be read. 

If the record pointer addresses the last record in a cyclic EF, READ RECORD (next) shall set the record pointer 
to the first record in this EF and this record shall be read. 
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PREVIOUS: The record pointer is decremented before the READ RECORD function is performed and the 
pointed record is read. If the record pointer has not been previously set within the selected EF, then READ 
RECORD (previous) shall read the last record and set the record pointer to this record. 

If the record pointer addresses the first record in a linear fixed EF, READ RECORD (previous) shall not cause 
the record pointer to be changed, and no data shall be read. 

If the record pointer addresses the first record in a cyclic EF, READ RECORD (previous) shall set the record 
pointer to the last record in this EF and this record shall be read. 

Input: 

mode, record number (absolute mode only) and the length of the record. 
Output: 

the record. 



8.6 UPDATE RECORD 



This function updates one complete record in the current linear fixed or cycUc EF. This function shall only be performed 
if the UPDATE access condition for this EF is satisfied. The UPDATE can be considered as a replacement of the 
relevant record data of the EF by the record data given in the command. The record pointer shall not be changed by an 
unsuccessful UPDATE RECORD function. 

The record to be updated is described by the modes below. Four modes are defined of which only PREVIOUS is 
allowed for cyclic files: 

CURRENT: The current record is updated. The record pointer is not affected. 

ABSOLUTE: The record given by the record number is updated. The record pointer is not affected. 

NEXT: The record pointer is incremented before the UPDATE RECORD function is performed and the pointed 
record is updated. If the record pointer has not been previously set within the selected EF, then UPDATE 
RECORD (next) shall set the record pointer to the first record in this EF and this record shall be updated. If the 
record pointer addresses the last record in a linear fixed EF, UPDATE RECORD (next) shall not cause the record 
pointer to be changed, and no record shall be updated. 

PREVIOUS: For a linear fixed EF the record pointer is decremented before the UPDATE RECORD function is 
performed and the pointed record is updated. If the record pointer has not been previously set within the selected 
EF, then UPDATE RECORD (previous) shall set the record pointer to the last record in this EF and this record 
shall be updated. If the record pointer addresses the first record in a linear fixed EF, UPDATE RECORD 
(previous) shall not cause the record pointer to be changed, and no record shall be updated. 

For a cyclic EF the record containing the oldest data is updated, the record pointer is set to this record and this 
record becomes record number 1 . 

Input: 

mode, record number (absolute mode only) and the length of the record; 

the data used for updating the record. 
Output: 

none. 

8.7 SEEK 

This function searches through the current linear fixed EF to find a record starting with the given pattern. This function 
shall only be performed if the READ access condition for this EF is satisfied. Two types of SEEK are defined: 

Type 1 The record pointer is set to the record containing the pattern, no output is available. 

Type 2 The record pointer is set to the record containing the pattern, the output is the record number. 

NOTE: A Phase 1 SIM only executes type 1 of the SEEK function. 
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The SIM shall be able to accept any pattern length from 1 to 16 bytes inclusive. The length of the pattern shall not 
exceed the record length. 

Four modes are defined: 

from the beginning forwards; 
from the end backwards; 
from the next location forwards; 
from the previous location backwards. 

If the record pointer has not been previously set (its status is undefined) within the selected linear fixed EF, then the 
search begins: 

with the first record in the case of SEEK from the next location forwards; or 
with the last record in the case of SEEK from the previous location backwards. 

After a successful SEEK, the record pointer is set to the record in which the pattern was found. The record pointer shall 
not be changed by an unsuccessful SEEK function. 

Input: 

type and mode; 

- pattern; 

length of the pattern. 
Output: 

type 1: none; 

type 2: status/record number 

8.8 INCREASE 

This function adds the value given by the ME to the value of the last increased/updated record of the current cyclic EF, 
and stores the result into the oldest record. The record pointer is set to this record and this record becomes record 
number 1 . This function shall be used only if this EF has an INCREASE access condition assigned and this condition is 
fulfilled (see bytes 8 and 10 in the response parameters/data of the current EF, clause 9). The SIM shall not perform the 
increase if the result would exceed the maximum value of the record (represented by all bytes set to 'FF'). 

Input: 

the value to be added. 
Output: 

value of the increased record; 

value which has been added. 

8.9 VERIFY CHV 

This function verifies the CHV presented by the ME by comparing it with the relevant one stored in the SIM. The 
verification process is subject to the following conditions being fulfilled: 

- CHV is not disabled; 

- CHV is not blocked. 

If the access condition for a function to be performed on the last selected file is CHVl or CHV2, then a successful 
verification of the relevant CHV is required prior to the use of the function on this file unless the CHV is disabled. 

If the CHV presented is correct, the number of remaining CHV attempts for that CHV shall be reset to its initial value 3. 

If the CHV presented is false, the number of remaining CHV attempts for that CHV shall be decremented. After 3 
consecutive false CHV presentations, not necessarily in the same card session, the respective CHV shall be blocked and 
the access condition can never be fulfilled until the UNBLOCK CHV function has been successfully performed on the 
respective CHV. 

Input: 

- indication CHV1/CHV2, CHV. 
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Output: 
none. 

8.10 CHANGE CHV 

This function assigns a new value to the relevant CHV subject to the following conditions being fulfilled: 

- CHV is not disabled; 

- CHV is not blocked. 

The old and new CHV shall be presented. 

If the old CHV presented is correct, the number of remaining CHV attempts for that CHV shall be reset to its initial 
value 3 and the new value for the CHV becomes valid. 

If the old CHV presented is false, the number of remaining CHV attempts for that CHV shall be decremented and the 
value of the CHV is unchanged. After 3 consecutive false CHV presentations, not necessarily in the same card session, 
the respective CHV shall be blocked and the access condition can never be fulfilled until the UNBLOCK CHV function 
has been performed successfully on the respective CHV. 

Input: 

- indication CHV1/CHV2, old CHV, new CHV. 
Output: 

none. 

8.11 DISABLE CHV 

This function may only be applied to CHVl. The successful execution of this function has the effect that files protected 
by CHVl are now accessible as if they were marked "ALWAYS". The function DISABLE CHV shall not be executed 
by the SIM when CHVl is already disabled or blocked. 

If the CHVl presented is correct, the number of remaining CHVl attempts shall be reset to its initial value 3 and CHVl 
shall be disabled. 

If the CHVl presented is false, the number of remaining CHVl attempts shall be decremented and CHVl remains 
enabled. After 3 consecutive false CHVl presentations, not necessarily in the same card session, CHVl shall be blocked 
and the access condition can never be fulfilled until the UNBLOCK CHV function has been successfully performed on 
CHVl. 

Input: 

- CHVl. 
Output: 

none. 

8.12 ENABLE CHV 

This function may only be appUed to CHV 1 . It is the reverse function of DISABLE CHV. The function ENABLE CHV 
shall not be executed by the SIM when CHVl is already enabled or blocked. 

If the CHVl presented is correct, the number of remaining CHVl attempts shall be reset to its initial value 3 and CHVl 
shall be enabled. 

If the CHVl presented is false, the number of remaining CHVl attempts shall be decremented and CHVl remains 
disabled. After 3 consecutive false CHVl presentations, not necessarily in the same card session, CHVl shall be 
blocked and may optionally be set to "enabled". Once blocked, the CHVl can only be unblocked using the UNBLOCK 
CHV function. If the CHVl is blocked and "disabled", the access condition shall remain granted. If the CHVl is 
blocked and "enabled", the access condition can never be fulfilled until the UNBLOCK CHV function has been 
successfully performed on CHVl. 
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8.13 UNBLOCK CHV 

This function unblocks a CHV which has been blocked by 3 consecutive wrong CHV presentations. This function may 
be performed whether or not the relevant CHV is blocked. 

If the UNBLOCK CHV presented is correct, the value of the CHV, presented together with the UNBLOCK CHV, is 
assigned to that CHV, the number of remaining UNBLOCK CHV attempts for that UNBLOCK CHV is reset to its 
initial value 10 and the number of remaining CHV attempts for that CHV is reset to its initial value 3. After a successful 
unblocking attempt the CHV is enabled and the relevant access condition level is satisfied. 

If the presented UNBLOCK CHV is false, the number of remaining UNBLOCK CHV attempts for that UNBLOCK 
CHV shall be decremented. After 10 consecutive false UNBLOCK CHV presentations, not necessarily in the same card 
session, the respective UNBLOCK CHV shall be blocked. A false UNBLOCK CHV shall have no effect on the status of 
the respective CHV itself. 

Input: 

- indication CHV1/CHV2, the UNBLOCK CHV and the new CHV. 
Output: 
none. 

8.14 INVALIDATE 

This function invalidates the current EF. After an INVALIDATE function the respective flag in the file status shall be 
changed accordingly. This function shall only be performed if the INVALIDATE access condition for the current EF is 
satisfied. 

An invalidated file shall no longer be available within the application for any function except for the SELECT and the 
REHABILITATE functions unless the file status of the EF indicates that READ and UPDATE may also be performed. 

Input: 

none. 
Output: 

none. 

8.15 REHABILITATE 

This function rehabilitates the invalidated current EF. After a REHABILITATE function the respective flag in the file 
status shall be changed accordingly. This function shall only be performed if the REHABILITATE access condition for 
the current EF is satisfied. 

If BDN is enabled (see clause 11.5.1) then the REHABILITATE function shall not rehabilitate the invalidated EFjjyj^j 
and EFlq(^j until the PROFILE DOWNLOAD procedure is performed indicating that the ME supports the "Call control 
by SIM" facility (see GSM 11.14 [27]). 

Input: 

none. 
Output: 

none. 

8.1 6 RUN GSM ALGORITHM 

This function is used during the procedure for authenticating the SIM to a GSM network and to calculate a cipher key. 
The card runs the specified algorithms A3 and A8 using a 16 byte random number and the subscriber authentication key 
Ki, which is stored in the SIM. The function returns the calculated response SRES and the cipher key Kc. 

The function shall not be executable unless DF^^jy] or any sub-directory under DFgsm has been selected as the Current 
Directory and a successful CHVl verification procedure has been performed (see 1 1.3.1). 

Input: 
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- RAND. 

Output: 

- SRES, Kc. 

The contents of Kc shall be presented to algorithm A5 by the ME in its full 64 bit format as delivered by the SIM. 

8.17 SLEEP 

This is an obsolete GSM function which was issued by Phase 1 MEs. The function shall not be used by an ME of Phase 
2 or later. 

8.18 TERMINAL PROFILE 

This function is used by the ME to transmit to the SIM its capabilities concerning the SIM Application Toolkit 
functionality. 

Input: 

terminal profile. 
Output: 



8.19 ENVELOPE 

This function is used to transfer data to the SIM Application Toolkit applications in the SIM. 

Input: 

data string. 
Output: 
- The structure of the data is defined in GSM 11.14 [27] . 

8.20 FETCH 

This function is used to transfer an Application Toolkit command from the SIM to the ME. 

Input: 

none. 
Output: 

data string containing an SIM Application Toolkit command for the ME. 



8.21 TERMINAL RESPONSE 



This function is used to transfer from the ME to the SIM the response to a previously fetched SIM Application Toolkit 
command. 

Input: 

data string containing the response. 
Output: 

none. 



9 Description of the commands 

This clause states the general principles for mapping the functions described in clause 8 onto Application Protocol Data 
Units which are used by the transmission protocol. 
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9.1 Mapping principles 

An APDU can be a command APDU or a response APDU. 
A command APDU has the following general format: 



CLA 


INS 


PI 


P2 


P3 


Data 



The response APDU has the following general format: 



Data 



SWl SW2 



An APDU is transported by the T=0 transmission protocol without any change. Other protocols might embed an APDU 
into their own transport structure (ISO/IEC 7816-3 [26]). 

The bytes have the following meaning: 

- CLA is the class of instruction (ISO/IEC 78 16-3 [26]), 'AO' is used in the GSM application; 

INS is the instruction code (ISO/IEC 7816-3 [26]) as defined in this subclause for each command; 

PI, P2, P3 are parameters for the instruction. They are specified in table 9. 'FF' is a valid value for PI, P2 and P3. 

P3 gives the length of the data element. P3='00' introduces a 256 byte data transfer from the SIM in an outgoing 

data transfer command (response direction). In an ingoing data transfer command (command direction), P3='00' 

introduces no transfer of data. 

SWl and SW2 are the status words indicating the successful or unsuccessful outcome of the command. 

For some of the functions described in clause 8 it is necessary for T=0 to use a supplementary transport service 
command (GET RESPONSE) to obtain the output data. For example, the SELECT function needs the following two 
commands: 

the first command (SELECT) has both parameters and data serving as input for the function; 

the second command (GET RESPONSE) has a parameter indicating the length of the data to be returned. 

If the length of the response data is not known beforehand, then its correct length may be obtained by applying the first 
command and interpreting the status words. SWl shall be '9F' and SW2 shall give the total length of the data. Other 
status words may be present in case of an error. The various cases are: 



Case 1: No input / No output 



CLA 



PI 



P2 



P3 



\ 

Igth (='00') 



SWl 



SW2 



'90' 



'00' 



Case 2: No input / Output of known length 

I CLA I INS I PI I P2 I P3 
1 

Igth 



DATA with length Igth 



SWl 



'90' 



SW2 



'00' 



NOTE: lgth='00' causes a data transfer of 256 bytes. 
Case 3: No Input / Output of unknown length 



CLA 



INS 



PI 



P2 



P3 



\ 

Igth (='00') 



SWl 



SW2 



Igth^ 



GET RESPONSE 
I CLA I INS 



PI 



P2 



P3 



1 

Igth, 



DATA with length Igth, < Igth^ SWl SW2 

— \ — — r~ 

'90' '00' 
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Case 4: Input / No output 



CLA 



INS 



PI 



P2 



P3 



DATA with length Igth 



Igth 



SWl 



' 90' 



SW2 



'00' 



Case 5: Input / Output of known or unknown length 

I CLA I INS I PI I P2 I P3 I DATA with length Igth 
^ 

Igth 



SWl 

~~r~ 



SW2 



Igth^ 



GET RESPONSE 
I CLA I INS 



PI 



P2 



P3 



Igth, 



DATA with length Igth, < Igth^ SWl SW2 

— \ — — r~ 

'90' '00' 



For cases 3 and 5, when SW1/SW2 indicates there is response data (i.e. SW1/SW2 = '9FXX'), then, if the ME requires 
to get this response data, it shall send a GET RESPONSE command as described in the relevant case above. 

For case 5, in case of an ENVELOPE for SIM data download, SW1/SW2 may also indicate that there is response data 
with the value '9EXX', and the ME shall then send a GET RESPONSE command to get this response data. 

If the GSM application is one of several applications in a multi-application card, other commands with CLA not equal to 
'AO' may be sent by the terminal. This shall not influence the state of the GSM application. 

The following diagrams show how the five cases of transmission protocol identified in the above diagrams can all be 
used to send pro-active SIM commands. For further information on the diagrams below see GSM 11. 14 [27]. 



Case 1: No input / "OK" response with no output, plus additional command from SIM 

I CLA I INS I PI I P2 I P3 I 



\ 

Igth (='00') 



SWl 



SW2 



"1 1 

91' Igth-, 



[Possible "normal GSM operation" command/response pairs] 



FETCH 

I CLA I INS 



PI 



P2 



P3 



DATA with length Igth^ 



igth. 



SWl 



'90' 



SW2 



'00' 



NOTE: lgth|='00' causes a data transfer of 256 bytes. 
Case 2: No input / "OK" response with data of known length, plus additional command from SIM 

I DATA with length Igth I 



CLA 



INS 



PI 



P2 



P3 



1 

Igth 



SWl 



"T" 

'91' 



SW2 



Igth-, 



[Possible "normal GSM operation" command/response pairs] 



FETCH 
I CLA 



INS 



PI 



P2 



P3 



DATA with length Igth^ 



1 

Igth-, 



SWl 



"T" 
'90' 



SW2 



'00' 



NOTE: lgth='00' causes a data transfer of 256 bytes. The same applies to Igthi. 
Case 3: No Input / "OK" response with data of unknown length, plus additional command from SIM 



CLA 



INS 



PI 



P2 



P3 



SWl 



\ 

Igth (='00') 



SW2 



Igth, 
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GET RESPONSE 

I CLA I INS I PI I P2 I P3 
1 

Igth, 



DATA with length Igthg < Igth^ I SWl I SW2 

\ 1 

'91' Igth^ 



[Possible "normal GSM operation" command/response pairs] 



FETCH 

I CLA I INS I PI I P2 I P3 



1 

Igth^ 



DATA with length Igthg I SWl I SW2 

— \ — — r~ 

'90' '00' 



Case 4: Input / "OK" response with no output data, plus additional command from SIM 

I CLA I INS I PI I P2 I P3 I DATA with length Igth I I SWl I SW2 

\ 1 

'91' Igthi 



1 

Igth 



[Possible "normal GSM operation" command/response pairs] 



FETCH 

I CLA I INS I PI I P2 I P3 
1 

Igth^ 



DATA with length Igth^ SWl SW2 

— \ — — r~ 

'90' '00' 



Case 5: Input / "OK" response with data of known or unknown length, plus additional command from SIM 



CLA INS PI P2 P3 DATA with length Igth 
^ 

Igth 



SWl SW2 

~~1 1 

'9F' igth-, 



GET RESPONSE 

I CLA I INS I PI 



P2 P3 



Igth, 



DATA with length lgth2<lgth^ I SWl I SW2 

\ 1 

'91' igth-, 



[Possible "normal GSM operation" command/response pairs] 



FETCH 

I CLA I INS 



PI 



P2 P3 



DATA with length igth. 



1 

igth-, 



SWl SW2 



T 



T 



'90' '00' 



9.2 Coding of the commands 



Table 9 below gives the coding of the commands. The direction of the data is indicated by (S) and (R), where (S) stands 
for data sent by the ME while (R) stands for data received by the ME. Offset is coded on 2 bytes where PI gives the 
high order byte and P2 the low order byte. '00 00' means no offset and reading/updating starts with the first byte while an 
offset of '00 or means that reading/updating starts with the second byte. 

In addition to the instruction codes specified in table 9 the following codes are reserved: 

GSM operational phase: 

'IX' with X even, from X=6 to X=E. 

Administrative management phase: 

'2A', 'DO', 'D2', 'DE', 'C4', 'C6', 'C8', 'CA', 'CC, 'B4', 'B6', 'B8', 'BA' and 'BC. 



£75/ 



(GSM 11.11 version 7.3.0 Release 1998) 



38 



ETSI TS 100 977 V7.3.0 (1999-07) 



Table 9: Coding of the commands 



COMMAND 


INS 


PI 


P2 


P3 


S/R 


SELECT 


'A4' 


'00' 


'00' 


'02' 


S/R 


STATUS 


'F2' 


'00' 


'00' 


igth 


R 


READ BINARY 


'BO' 


offset high 


offset low 


igth 


R 


UPDATE BINARY 


'D6' 


offset high 


offset low 


igth 


S 


READ RECORD 


'B2' 


rec No. 


mode 


Igth 


R 


UPDATE RECORD 


'DC 


rec No. 


mode 


Igth 


S 


SEEK 


'A2' 


'00' 


type/mode 


igth 


S/R 


INCREASE 


'32' 


'00' 


'00' 


'03' 


S/R 


VERIFY CHV 


'20' 


'00' 


CHV No. 


'08' 


S 


CHANGE CHV 


'24' 


'00' 


CHV No. 


'10' 


S 


DISABLE CHV 


'26' 


'00' 


'01' 


'08' 


S 


ENABLE CHV 


'28' 


'00' 


'01' 


'08' 


S 


UNBLOCK CHV 


'2C' 


'00' 


see note 


'10' 


S 


INVALIDATE 


'04' 


'00' 


'00' 


'00' 


_ 


REHABILITATE 


'44' 


'00' 


'00' 


'00' 


- 


RUN GSM ALGORITHM 


'88' 


'00' 


'00' 


'10' 


S/R 


SLEEP 


'FA' 


'00' 


'00' 


'00' 


- 


GET RESPONSE 


'CO' 


'00' 


'00' 


Igth 


R 


TERMINAL PROFILE 


'10' 


'00' 


'00' 


Igth 


S 


ENVELOPE 


'C2' 


'00' 


'00' 


Igth 


S/R 


FETCH 


'12' 


'00' 


'00' 


Igth 


R 


TERMINAL RESPONSE 


'14' 


'00' 


'00' 


igth 


S 



NOTE: If the UNBLOCK CHV command applies to CHVl then P2 is coded '00'; if it appUes to CHV2 then P2 is 
coded '02'. 

Definitions and codings used in the response parameters/data of the commands are given in subclause 9.3. 

9.2.1 SELECT 



COMMAND 


CLASS 


INS 


PI 


P2 


P3 


SELECT 


'AO' 


'A4' 


'00' 


'00' 


'02' 



Command parameters/data: 



Byte(s) 


Description 


Length 


1 -2 


File ID 


2 



Response parameters/data in case of an MF or DF: 



Byte(s) 


Description 


Length 


1 -2 


RFU 


2 


3-4 


Total amount of memory of the selected directory which is 
not allocated to any of the DFs or EFs under the selected 
directory 


2 


5-6 


File ID 


2 


7 


Type of file (see subclause 9.3) 


1 


8- 12 


RFU 


5 


13 


Length of the following data (byte 14 to the end) 


1 


14-34 


GSM specific data 


21 
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GSM specific data: 



Byte(s) 


Description 


Length 


14 


File characteristics (see detail 1) 




15 


Number of DFs which are a direct child of the current 
directory 




16 


Number of EFs which are a direct child of the current 
directory 




17 


Number of CHVs, UNBLOCK CHVs and administrative 
codes 




18 


RFU 




19 


CHV1 status (see detail 2) 




20 


UNBLOCK CHV1 status (see detail 2) 




21 


CHV2 status (see detail 2) 




22 


UNBLOCK CHV2 status (see detail 2) 




23 


RFU 




24-34 


Reserved for the administrative management 


. Igth . 1 1 



Bytes 1 - 22 are mandatory and shall be returned by the SIM. Bytes 23 and following are optional and may not be 
returned by the SIM. 

NOTE 1: Byte 35 and following are RFU. 

NOTE 2: The STATUS information of the MF, DFQgjyj and DFjgLECOM provide some identical application 

specific data, e.g. CHV status. On a multi-application card the MF should not contain any application 
specific data. Such data is obtained by terminals from the specific application directories. ME 
manufacturers should take this into account and therefore not use application specific data which may 
exist in the MF of a mono-application SIM. 

Similarly, the VERIFY CHV command should not be executed in the MF but in the relevant application 
directory (e.g. DFqsm)- 

Detail 1 : File characteristics 



b7 b6 b5 b4 b3 b2 bl 



Clock stop (see below) 

For running the authentication algorithm, or the 
ENVELOPE command for SIM Data Download, a frequency 
is required of at least 13/8 MHz if b2=0 and 13/4 
MHz if b2=l 
Clock stop (see below) 
"for coding (see GSM 11.12 [28]) 

"rfu 

"b8=0: CHVl enabled; b8=l: CHVl disabled 



The coding of the conditions for stopping the clock is as follows: 



itbl 


Bitb3 


Bitb4 


1 








1 


1 





1 





1 














1 











1 



clock stop allowed, no preferred level 
clock stop allowed, high level preferred 
clock stop allowed, low level preferred 
clock stop not allowed 
clock stop not allowed, unless at high level 
clock stop not allowed, unless at low level 



If bit bl (column 1) is coded 1, stopping the clock is allowed at high or low level. In this case columns 2 (bit b3) 
and 3 (bit b4) give information about the preferred level (high or low, respectively) at which the clock may be 
stopped. 

If bit bl is coded 0, the clock may be stopped only if the mandatory condition in column 2 (b3=l, i.e. stop at high 
level) or column 3 (b4=l, i.e. stop at low level) is fulfilled. If all 3 bits are coded 0, then the clock shall not be 
stopped. 
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Detail 2: Status byte of a secret code 



b7 



b6 



b5 



b4 



b3 



b2 



bl 



Number of false presentations remaining 
( ' ' means blocked) 

"rfu 

b8=0 : secret code not initialised, 
b8=l: secret code initialised 



Response parameters/data in case of an EF: 



Byte(s) 


Description 


Length 


1 -2 


RFU 


2 


3-4 


File size 

(for transparent EF: the length of the body part of the EF) 
(for linear fixed or cyclic EF: record length multiplied by the 
number of records of the EF) 


2 


5-6 


File ID 


2 


7 


Type of file (see 9.3) 


1 


8 


see detail 3 


1 


9-11 


Access conditions (see 9.3) 


3 


12 


File status (see 9.3) 


1 


13 


Length of the following data (byte 14 to the end) 


1 


14 


Structure of EF (see 9.3) 


1 


15 


Length of a record (see detail 4) 


1 


16 and 
following 


RFU 


- 



Bytes 1-14 are mandatory and shall be returned by the SIM. 

Byte 15 is mandatory in case of linear fixed or cyclic EFs and shall be returned by the SIM. 
Byte 15 is optional in case of transparent EFs and may not be returned by the SIM. 
Byte 16 and following (when defined) are optional and may not be returned by the SIM. 

Detail 3: Byte 8 

For transparent and linear fixed EFs this byte is RFU. For a cyclic EF all bits except bit 7 are RFU; b7=l 
indicates that the INCREASE command is allowed on the selected cyclic file. 

Detail 4: Byte 15 

For cyclic and linear fixed EFs this byte denotes the length of a record. For a transparent EF, this byte shall be 
coded '00', if this byte is sent by the SIM. 

9.2.2 STATUS 



COIUIIUIAND 


CLASS 


INS 


PI 


P2 


P3 


STATUS 


'AO' 


'F2' 


'00' 


'00' 


igth 



The response parameters/data are identical to the response parameters/data of the SELECT command in case of an MF 
orDF. 

9.2.3 READ BINARY 



COMMAND 


CLASS 


INS 


PI 


P2 


P3 


READ BINARY 


'AO' 


'BO' 


offset high 


offset low 


Igth 
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Response parameters/data: 



Byte(s) 


Description 


Length 


1 - Igth 


Data to be read 


Igth 



9.2.4 UPDATE BINARY 



COIUIIUIAND 


CLASS 


INS 


PI 


P2 


P3 


UPDATE BINARY 


'AO' 


'D6' 


offset high 


offset low 


Igth 



Command parameters/data: 



Byte(s) 


Description 


Length 


1 - Igth 


Data 


Igth 



9.2.5 READ RECORD 



COMMAND 


CLASS 


INS 


PI 


P2 


P3 


READ RECORD 


'AO' 


'B2' 


Rec.No. 


Mode 


Igth 



Parameter P2 specifies the mode: 
'02' = next record; 
'03' = previous record; 
'04' = absolute mode/current mode, the record number is given in PI with PI ='00' denoting the current record. 

For the modes "next" and "previous" PI has no significance and shall be set to '00' by the ME. To ensure phase 
compatibility between Phase 2 SIMs and Phase 1 MEs, the SIM shall not interpret the value given by the ME. 

Response parameters/data: 



9.2.6 



Byte(s) 


Description 


Length 




1 - Igth 


The data of the record 


Igth 




UPDATE RECORD 










COMMAND 


CLASS 


INS 


PI 


P2 


P3 


UPDATE RECORD 


'AO' 


'DC 


Rec.No. 


Mode 


Igth 



Parameter P2 specifies the mode: 
'02' = next record; 
'03' = previous record; 
'04' = absolute mode/current mode; the record number is given in PI with PI ='00' denoting the current record. 

For the modes "next" and "previous" PI has no significance and shall be set to '00' by the ME. To ensure phase 
compatibility between Phase 2 SIMs and Phase 1 MEs, the SIM shall not interpret the value given by the ME. 

Command parameters/data: 



9.2.7 



Byte(s) 


Description 


Length 




1 - Igth 


Data 


Igth 




SEEK 












COMMAND 


CLASS 


INS 


PI 


P2 


P3 


SEEK 


'AC 


'A2' 


'00' 


Type/Mode 


Igth 



Parameter P2 specifies type and mode: 

'xO' = from the beginning forward; 
'xl' = from the end backward; 
'x2' = from the next location forward; 
'x3' = from the previous location backward 
with x='0' specifies type 1 and x='r specifies type 2 of the SEEK command. 
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Command parameters/data: 



Byte(s) 


Description 


Length 


1 - Igth 


Pattern 


Igth 



There are no response parameters/data for a type 1 SEEK. A type 2 SEEK returns the following response 
parameters/data: 



Byte(s) 


Description 


Length 


1 


Record number 


1 



9.2.8 INCREASE 



COIUIMAND 


CLASS 


INS 


PI 


P2 


P3 


INCREASE 


AO' 


'32' 


'00' 


'00' 


'03' 



Command parameters/data: 



Byte(s) 


Description 


Length 


1 -3 


Value to be added 


3 



Response parameters/data: 



Byte(s) 


Description 


Length 


1 -X 


Value of the increased record 


X 


X+1 - X+3 


Value which has been added 


3 



NOTE: X denotes the length of the record. 



9.2.9 VERIFY CHV 



COMMAND 


CLASS 


INS 


PI 


P2 


P3 


VERIFY CHV 


'AO' 


'20' 


'00' 


CHV No. 


'08' 



Parameter P2 specifies the CHV: 

- '01' = CHV1; 

- '02' = CHV2. 

Command parameters/data: 



Byte(s) 


Description 


Length 


1 -8 


CHV value 


8 



9.2.10 CHANGE CHV 



COMMAND 


CLASS 


INS 


PI 


P2 


P3 


CHANGE CHV 


'AO' 


'24' 


'00' 


CHV No. 


'10' 



Parameter P2 specifies the CHV: 

- '01' = CHV1; 

- '02' = CHV2. 
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Command parameters/data: 



Byte(s) 


Description 


Length 


1 -8 


Old CHV value 


8 


9-16 


New CHV value 


8 



9.2.11 DISABLE CHV 



COIUIIUIAND 


CLASS 


INS 


PI 


P2 


P3 


DISABLE CHV 


'AO' 


'26' 


'00' 


'01' 


'08' 



Command parameters/data: 



Byte(s) 


Description 


Length 


1 -8 


CHV1 value 


8 



9.2.12 ENABLE CHV 



COMMAND 


CLASS 


INS 


PI 


P2 


P3 


ENABLE CHV 


'AO' 


'28' 


'00' 


'01' 


'08' 



Command parameters/data: 



Byte(s) 


Description 


Length 


1 -8 


CHV1 value 


8 



9.2.13 UNBLOCK CHV 



COMMAND 


CLASS 


INS 


PI 


P2 


P3 


UNBLOCK CHV 


'AO' 


'2C' 


'00' 


CHV No. 


'10' 



Parameter P2 specifies the CHV: 

- 00 = CHV1; 

- 02 = CHV2. 

NOTE: The coding '00' for CHVl differs from the coding of CHVl used for other commands. 
Command parameters/data: 



Byte(s) 


Description 


Length 


1 -8 


UNBLOCK CHV value 


8 


9-16 


New CHV value 


8 



9.2.14 INVALIDATE 



COMMAND 


CLASS 


INS 


PI 


P2 


P3 


INVALIDATE 


'AO' 


'04' 


'00' 


'00' 


'00' 



9.2.15 REHABILITATE 



COMMAND 


CLASS 


INS 


PI 


P2 


P3 


REHABILITATE 


'AO' 


'44' 


'00' 


'00' 


'00' 



9.2.16 RUN GSM ALGORITHM 



COMMAND 


CLASS 


INS 


PI 


P2 


P3 


RUN GSM 
ALGORITHM 


'AO' 


'88' 


'00' 


'00' 


'10' 
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Command parameters/data: 



Byte(s) 


Description 


Length 


1 -16 


RAND 


16 



Response parameters/data: 



Byte(s) 


Description 


Length 


1 -4 


SRES 


4 


5- 12 


Cipher Key Kc 


8 



The most significant bit of SRES is coded on bit 8 of byte 1 . The most significant bit of Kc is coded on bit 8 of byte 5. 

9.2.17 SLEEP 



COIUIIUIAND 


CLASS 


INS 


PI 


P2 


P3 


SLEEP 


'AO' 


'FA' 


'00' 


'00' 


'00' 



NOTE: This command is used by Phase 1 MEs only. 



9.2.18 GET RESPONSE 



COMMAND 


CLASS 


INS 


PI 


P2 


P3 


GET RESPONSE 


'AO' 


'CO' 


'00' 


'00' 


igth 



The response data depends on the preceding command. Response data is available after the commands RUN GSM 
ALGORITHM, SEEK (type 2), SELECT, INCREASE, and ENVELOPE. If the command GET RESPONSE is 
executed, it is required that it is executed immediately after the command it is related to (no other command shall come 
between the command/response pair and the command GET RESPONSE). If the sequence is not respected, the SIM 
shall send the status information "technical problem with no diagnostic given" as a reaction to the GET RESPONSE. 

Since the MP is implicitly selected after activation of the SIM, GET RESPONSE is also allowed as the first command 
after activation. 

The response data itself is defined in the subclause for the corresponding command. 

9.2.19 TERMINAL PROFILE 



COMMAND 


CLASS 


INS 


PI 


P2 


P3 


TERMINAL PROFILE 


'AO' 


'10' 


'00' 


'00' 


Igth 



Command parameters/data: 

length Igth . The structure of the command parameters is defined in GSM 1L14 [27]. 
Response parameters/data: 

none available 

9.2.20 ENVELOPE 



COMMAND 


CLASS 


INS 


PI 


P2 


P3 


ENVELOPE 


'AO' 


'C2' 


'00' 


'00' 


Igth 



Command parameters/data: 

length Igth . The structure of the command parameters is defined in GSM 1L14 [27]. 
Response parameters/data: 

The structure of the data is defined in GSM 1L14 [27]. 
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9.2.21 FETCH 



COMMAND 


CLASS 


INS 


PI 


P2 


P3 


FETCH 


'AO' 


'12' 


'00' 


'00' 


igth 



Command parameters/data: 

none. 
Response parameters/data: 

length Igth . The structure of the data is defined in GSM 11.14 [27]. 

9.2.22 TERMINAL RESPONSE 



COMMAND 


CLASS 


INS 


PI 


P2 


P3 


TERMINAL 
RESPONSE 


'AO' 


'14' 


'00' 


'00' 


Igth 



Command parameters/data: 

length Igth . The structure of the command parameters is defined in GSM 11.14 [27]. 
Response parameters/data: 

none available. 



9.3 Definitions and coding 



The following definitions and coding are used in the response parameters/data of the commands. 

Coding 

Each byte is represented by bits b8 to bl, where b8 is the most significant bit (MSB) and bl is the least significant bit 
(LSB). In each representation the leftmost bit is the MSB. 

RFU 

In a GSM specific card all bytes which are RFU shall be set to '00' and RFU bits to 0. Where the GSM application exists 
on a multiapplication card or is built on a generic telecommunications card (e.g. TE9) then other values may apply. The 
values will be defined in the appropriate specifications for such cards. These bytes and bits shall not be interpreted by an 
ME in a GSM session. 

File status 



b8 



b7 



b6 



b5 



b4 



b3 



b2 



bl 



bl=0 ; invalidated; bl=l ; not invalidated 

"rfu 

b3=0 ; not readable or updatable when invalidated 
b3=l ; readable and updatable when invalidated 

"rfu 



Bit b3 may be set to 1 in special circumstances when it is required that the EF can be read and updated even if the EF is 
invalidated, e.g. reading and updating the EF^dn when the FDN feature is enabled, or reading and updating the EEgj-,;,^ 
when the BDN feature is disabled. 

Structure of file 

'00' transparent; 
'01' linear fixed; 
'03' cyclic. 

Type of File 

- '00' RFU; 

- '01' MF; 

- '02' DF; 

- '04' EF. 
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Coding of CHVs and UNBLOCK CHVs 

A CHV is coded on 8 bytes. Only (decimal) digits (0-9) shall be used, coded in CCITT T.50 [20] with bit 8 set to zero. 
The minimum number of digits is 4. If the number of digits presented by the user is less than 8 then the ME shall pad the 
presented CHV with 'FF' before sending it to the SIM. 

The coding of the UNBLOCK CHVs is identical to the coding of the CHVs. However, the number of (decimal) digits is 
always 8. 

Coding of Access Conditions 

The access conditions for the commands are coded on bytes 9, 10 and 11 of the response data of the SELECT command. 
Each condition is coded on 4 bits as shown in table 10. 

Table 10: Access conditions 



ALW 


'0'* 


CHV1 


'1'* 


CHV2 


'2'* 


RFU 


'3' 


ADM 


'4' 






ADM 


'E' 


NEW 


,p, * 



Entries marked "*" in the table above, are also available for use as administrative codes in addition to the ADM access 
levels '4' to 'E' (refer to subclause 7.3) if required by the appropriate administrative authority. If any of these access 
conditions are used, the code returned in the Access Condition bytes in the response data shall be the code applicable to 
that particular level. 

Byte 9: 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 














L 


-L 


JL 


JL 


UPDATE 
READ; SEEK 


1( 


): 


















b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 














L 


-L 


-^ 


-^ 


RFU 
INCREASE 


1 


I: 


















b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 














1 


1 


1 


1 


INVALIDATE 












REHABILITATE 



9.4 Status conditions returned by the card 

This subclause specifies the coding of the status words SWl and SW2. 
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9.4.1 Responses to commands which are correctly executed 



9.4.2 



9.4.3 



9.4.4 



9.4.5 



SW1 


SW2 


Description 


'90' 


'00' 


- normal ending of the command 


'91' 


'XX' 


- normal ending of the command, with extra information from the 
proactive SIM containing a command for the ME. Length 'XX' of the 
response data 


'9E' 


'XX' 


- length 'XX' of the response data given in case of a SIM data download 
error 


'9F' 


'XX' 


- length 'XX' of the response data 


Responses to commands which are postponed 


SW1 


SW2 


Error description 


'93' 


'00' 


- SIM Application Toolkit is busy. Command cannot be executed at 
present, further normal commands are allowed. 


Memory management 


SW1 


SW2 


Error description 


'92' 


'OX' 


- command successful but after using an internal update retry routine 
'X' times 


'92' 


'40' 


- memory problem 


Referencing management 


SW1 


SW2 


Error description 


'94' 


'00' 


- no EF selected 


'94' 


'02' 


- out of range (invalid address) 


'94' 


'04' 


- file ID not found 

- pattern not found 


'94' 


'08' 


- file is inconsistent with the command 


Security management 


SW1 


SW2 


Error description 


'98' 


'02' 


- no CHV initialized 


'98' 


'04' 


- access condition not fulfilled 

- unsuccessful CHV verification, at least one attempt left 

- unsuccessful UNBLOCK CHV verification, at least one attempt left 

- authentication failed (see note) 


'98' 


'08' 


- in contradiction with CHV status 


'98' 


'10' 


- in contradiction with invalidation status 


'98' 


'40' 


- unsuccessful CHV verification, no attempt left 

- unsuccessful UNBLOCK CHV verification, no attempt left 

- CHV blocked 

- UNBLOCK CHV blocked 


'98' 


'50' 


- increase cannot be performed, Max value reached 



NOTE: A Phase 1 SIM may send this error code after the third consecutive unsuccessful CHV verification attempt 
or the tenth consecutive unsuccessful unblocking attempt. 



9.4.6 Application independent errors 



SW1 


SW2 


Error description 


'67' 


'XX' 


- incorrect parameter P3 (see note) 


'6B' 


'XX'# 


- incorrect parameter PI or P2 (see **) 


'6D' 


'XX'* 


- unknown instruction code given in the command 


'6E' 


'XX'* 


- wrong instruction class given in the command 


'6F' 


'XX'# 


- technical problem with no diagnostic given 
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* These values of 'XX' are specified by ISO/IEC; at present the default value 'XX'='00' is the only one defined. 

** When the error in PI or P2 is caused by the addressed record being out of range, then the return code '94 02' shall be 
used. 

NOTE: 'XX' gives the correct length or states that no additional information is given ('XX' = '00'). 

9.4.7 Commands versus possible status responses 

The following table shows for each command the possible status conditions returned (marked by an asterisk *). 

Table 1 1 : Commands and status words 





OK 


B 


Mem 


Refer. 


Security 


Application 






u 


Sta 


Status 


Status 


Independent 






s 








Errors 






y 












9 


9 


9 


9 


9 


9 


9 


9 


9 


9 


9 


9 


9 


9 


9 


9 


9 


6 


6 


6 


6 


6 







1 


E 


F 


3 


2 


2 


4 


4 


4 


4 


8 


8 


8 


8 


8 


8 


7 


B 


D 


E 


F 







X 


X 


X 








4 























1 


4 


5 


X 


X 


X 


X 


X 


Commands 





X 


X 


X 





X 








2 


4 


8 


2 


4 


8 











X 


X 


X 


X 


X 


Select 








* 






* 






* 
















* 


* 




* 


* 


Status 


* 


* 










* 






















* 


* 




* 


* 


Update Binary 


* 


* 








* 


* 


* 






* 




* 




* 






* 


* 




* 


* 


Update Record 


* 


* 








* 


* 


* 


* 




* 




* 




* 






* 


* 




* 


* 


Read Binary 


* 


* 










* 


* 






* 




* 




* 






* 


* 




* 


* 


Read Record 


* 


* 










* 


* 


* 




* 




* 




* 






* 


* 




* 


* 


Seel< 


* 






* 






* 


* 




* 


* 




* 




* 






* 


* 




* 


* 


Increase 








* 




* 


* 


* 






* 




* 




* 




* 


* 


* 




* 


* 


Verify CHV 


* 


* 








* 


* 










* 


* 


* 




* 




* 


* 




* 


* 


Change CHV 


* 


* 








* 


* 










* 


* 


* 




* 




* 


* 




* 


* 


Disable CHV 


* 


* 








* 


* 










* 


* 


* 




* 




* 


* 




* 


* 


Enable CHV 


* 


* 








* 


* 










* 


* 


* 




* 




* 


* 




* 


* 


Unblock CHV 


* 


* 








* 


* 










* 


* 


* 




* 




* 


* 




* 


* 


Invalidate 


* 


* 








* 


* 


* 










* 




* 






* 


* 




* 


* 


Rehabilitate 


* 


* 








* 


* 


* 










* 




* 






* 


* 




* 


* 


Run GSIVl Algorithm 








* 






* 








* 




* 










* 


* 




* 


* 


Sleep 


* 


































* 


* 




* 


* 


Get Response 


* 


* 










* 






















* 


* 




* 


* 


Terminal Profile 


* 


* 








* 


* 






















* 


* 




* 


* 


Envelope 


* 


* 


* 


* 


* 


* 


* 






















* 


* 




* 


* 


Fetch 


* 












* 






















* 


* 




* 


* 


Terminal Response 















































The responses '91 XX', and '93 00' and '9E XX' can only be given by a SIM supporting SIM Application Toolkit, to an 
ME also supporting SIM Application Toolkit. 

For the SEEK command the response '91 XX' can be given directly after a Type 1 SEEK command. Following the Type 
2 SEEK command the SIM can give the response '91 XX' only after the GET RESPONSE command. 



10 Contents of the Elementary Files (ef) 

This clause specifies the EFs for the GSM session defining access conditions, data items and coding. A data item is a 
part of an EF which represents a complete logical entity, e.g. the alpha tag in a EF^^j^ record. 
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EFs or data items having an unassigned value, or, which during the GSM session, are cleared by the ME, shall have their 
bytes set to 'FF'. After the administrative phase all data items shall have a defined value or have their bytes set to 'FF'. If 
a data item is 'deleted' during a GSM session by the allocation of a value specified in another GSM TS, then this value 
shall be used, and the data item is not unassigned; e.g. for a deleted LAI in EFloci the last byte takes the value 'FE' 
(GSM 04.08 [15] refers). 

EFs are mandatory (M) or optional (O). The file size of an optional EF may be zero. All implemented EFs with a file 
size greater than zero shall contain all mandatory data items. Optional data items may either be filled with 'F', or, if 
located at the end of an EF, need not exist. 

When the coding is according to CCITT Recommendation T.50 [20], bit 8 of every byte shall be set to 0. 

For an overview containing all files see figure 8. 

1 0.1 Contents of the EFs at the MF level 

There are only two EFs at the MF level. 

1 0.1 .1 EFicciD (ICC Identification) 

This EF provides a unique identification number for the SIM. 



Identifier: '2FE2' Structure: transparent Mandatory 


File size: 10 bytes Update activity: low 


Access Conditions: 

READ ALWAYS 
UPDATE NEVER 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1 -10 


Identification number 


M 


1 bytes 



Identification number 

Contents: 

according to CCITT Recommendation E.118 [18]. However, network operators who are already issuing 
Phase 1 SIM cards with an identification number length of 20 digits may retain this length. 

Purpose: 

card identification number. 

Coding: 

BCD, left justified and padded with 'F'; after padding the digits within a byte are swapped (see below). 
However, network operators who are already issuing Phase 1 SIM cards where the digits within a byte are not 
swapped may retain this configuration. 

Byte I: 



b7 b6 b5 b4 b3 b2 bl 



LSB of Digit 1 



MSB of Digit 1 
" LSB of Digit 2 



MSB of Digit 2 
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Byte 2: 



b7 



b6 



b5 



b4 



b3 



b2 



bl 



LSB of Digit 3 



MSB of Digit 3 
" LSB of Digit 4 



MSB of Digit 4 



etc. 

1 0.1 .2 EFelp (Extended language preference) 

This EF contains the codes for up to n languages. This information, determined by the user/operator, defines the 
preferred languages of the user in order of priority. This information may be used by the ME for MMI purposes and for 
short message handling (e.g. screening of preferred languages in SMS-CB). 

When the CB Message Identifier capability is both allocated and activated the ME selects only those CB messages the 
language of which corresponds to one of the languages given in this EF or in EFlp, whichever of these EFs is used (see 
subclause 1 1.2.1). The CB message language is recognized according to GSM 03.38 by its data coding scheme. 



Identifier: '2F 05' Structure: transparent Optional 


File size: 2n bytes Update activity: low 


Access Conditions: 

READ ALW 
UPDATE CHV1 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1 -2 


1^' language code (highest prior.) 





2 bytes 


3-4 


2"° language code 





2 bytes 










2n-1 - 2n 


nth language code (lowest prior.) 





2 bytes 



Coding: 

each language code is a pair of alpha-numeric characters, defined in ISO 639 [30]. Each alpha-numeric 
character shall be coded on one byte using the SMS default 7-bit coded alphabet as defined in GSM 03.38 
[12] with bit 8 set to 0. 

Unused language entries shall be set to 'FF FF'. 

1 0.2 DFs at the GSM application level 

For compatibility with other systems based on the GSM switching platform and for special GSM services, DFs may be 
present as child directories of DFqsm- The following have been defined: 



DFiRiDIUM 


'5F30 


DFglobalstar 


'5F31 


DFico 


'5F32 


DFACeS 


'5F33 


DFpcsi9oo 


'5F40 


DFcTs 


'5F60 


DFsoLSA 


'5F70 



Only the contents of DFsolsa are specified in the present document. For details of the EFs contained in the DFcts, see 

GSM 11.19 [34]. 
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1 0.3 Contents of files at the GSM application level 

The EFs in the Dedicated File OpQ^jy; contain network related information. 

10.3.1 EFlp (Language preference) 

This EF contains the codes for one or more languages. This information, determined by the user/operator, defines the 
preferred languages of the user in order of priority. This information may be used by the ME for MMI purposes and for 
short message handling (e.g. screening of preferred languages in SMS-CB). 

When the CB Message Identifier capability is both allocated and activated the ME selects only those CB messages the 
language of which corresponds to one of the languages given in this EF or in EFelp, whichever of these EFs is used (see 
subclause 11. 2.1). The CB message language is recognized according to GSM 03.41 by its data coding scheme. 



Identifier: '6F05' Structure: transparent Mandatory 


File size: 1 -n bytes Update activity: low 


Access Conditions: 

READ ALW 
UPDATE CHV1 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1 


1^' language code (highest prior.) 


M 


1 byte 


2 


2"° language code 





1 byte 










n 


nth language code (lowest prior.) 





1 byte 



Coding: according to GSM 03.41 [14]. 
Using the command GET RESPONSE, the ME can determine the size of the EF. 

10.3.2 EF,^si(IMSI) 

This EF contains the International Mobile Subscriber Identity (IMSI). 



Identifier: '6F07' Structure: transparent Mandatory 


File size: 9 bytes Update activity: low 


Access Conditions: 

READ CHV1 
UPDATE ADM 
INVALIDATE ADM 
REHABILITATE CHV1 


Bytes 


Description 


M/0 


Length 


1 


length of IMSI 


M 


1 byte 


2-9 


IMSI 


M 


8 bytes 



length of IMSI 
Contents: 

The length indicator refers to the number of significant bytes, not including this length byte, required for the 

IMSI. 
Coding: according to GSM 04.08 [15]. 

IMSI 
Contents: 

International Mobile Subscriber Identity. 
Coding: 

This information element is of variable length. If a network operator chooses an IMSI of less than 15 digits, 

unused nibbles shall be set to 'F'. 
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Byte 2: 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 
































L 


1 

























Parity 














LSB of Digit 1 






















































MSB of Digit 1 



For the parity bit, see GSM 04.08 [15]. 
Byte 3: 



b7 



b6 



b5 



b4 



b3 



b2 



bl 



LSB of Digit 2 



MSB of Digit 2 
" LSB of Digit 3 



MSB of Digit 3 



etc. 



1 0.3.3 EFkc (Ciphering key Kc) 

This EF contains the ciphering key Kc and the ciphering key sequence number n. 



Identifier: '6F20' 


Structure 


transparent 


Mandatory 


File size: 9 bytes 




Update activity: high 


Access Conditions: 
READ 
UPDATE 
INVALIDATE 
REHABILITATE 


CHV1 
CHV1 
ADM 
ADM 






Bytes 


Description 


M/0 


Length 


1 -8 


Ciphering key Kc 


M 


8 bytes 


9 


Ciphering key sequence number n 


M 


1 byte 



Ciphering key Kc 
Coding: 

The least significant bit of Kc is the least significant bit of the eighth byte. The most significant bit of Kc is 

the most significant bit of the first byte. 
Ciphering key sequence number n 
Coding: 



bits b4 to b8 are coded 



NOTE: GSM 04.08 [15] defines the value of n=l 1 1 as "key not available". Therefore the value '07' and not 'FF' 
should be present following the administrative phase. 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 
















1 1 1 

























10.3.4 EF 



PLMNsel 



(PLMN selector) 



This EF contains the coding for n PLMNs, where n is at least eight. This information determined by the user/operator 
defines the preferred PLMNs of the user in priority order. 
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Identifier: '6F30' Structure: transparent 


Optional 


File size: 3n (n • 8) bytes Update activity 


: low 


Access Conditions: 

READ CHV1 
UPDATE CHV1 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1 -3 


1"PLMN (highest priority) 


M 


3 bytes 










22-24 


8'" PLMN 


M 


3 bytes 


25-27 


9'" PLMN 





3 bytes 










{3n-2)-3n 


nth PLMN (lowest priority) 





3 bytes 



PLMN 

Contents: 

Mobile Country Code (MCC) followed by the Mobile Network Code (MNC). 
Coding: 

according to GSM 04.08 [15]. 

If storage for fewer than the maximum possible number n is required, the excess bytes shall be set to 'FF'. 
For instance, using 246 for the MCC and 8 1 for the MNC and if this is the first and only PLMN, the contents 
reads as follows: 

Bytes 1-3: '42"F6"18' 

Bytes 4-6: 'FF' 'FF' 'FF' 

etc. 



1 0.3.5 EFhplmn (HPLMN search period) 

This EF contains the interval of time between searches for the HPLMN (see GSM 02. 11 [5]). 



Identifier: '6F31' Structure: transparent Mandatory 


File size: 1 byte Update activity: low 


Access Conditions: 

READ CHV1 
UPDATE ADM 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1 


Time interval 


M 


1 byte 



Time interval 
Contents: 

The time interval between two searches. 
Coding: 

The time interval is coded in integer multiples of n minutes. The range is from n minutes to a maximum value. 

The value '00' indicates that no attempts shall be made to search for the HPLMN. The encoding is: 



'00' 
'01' 
'02' 



No HPLMN search attempts 
n minutes 
2n minutes 



'YZ': (16YH-Z)n minutes (maximum value) 
All other values shall be interpreted by the ME as a default period. 
For specification of the integer timer interval n, the maximum value and the default period refer to GSM 02. 11 [5]. 
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10.3.6 EF 



ACMmax 



(ACM maximum value) 



This EF contains the maximum value of the accumulated call meter. This EF shall always be allocated if EF^(-;jy[ is 
allocated. 



Identifier: '6F37' Structure: transparent Optional 


File size: 3 bytes Update activity: low 


Access Conditions: 

READ CHV1 
UPDATE CHV1/CHV2 

(fixed during administrative management) 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1 -3 


Maximum value 


M 


3 bytes 



Maximum value 
Contents: 

maximum value of the Accumulated Call Meter (ACM) 
Coding: 

First byte: 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 


1 


1 


1 


1 


1 


1 


1 


1 



2"^ 2' 



2ZU 2^^ 2^° 2-^' 2^ 



Second byte: 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 


1 


1 


1 


1 


1 


1 


1 


1 



Third byte: 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 


1 


1 


1 


1 


1 


1 


1 


1 



For instance, '00' '00' '30' represents 2^+2^. 
All ACM data is stored in the SIM and transmitted over the SIM/ME interface as binary. 
ACMmax is not valid, as defined in GSM 02.24 [7], if it is coded '000000'. 
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1 0.3.7 EFgsT (SIM service table) 



This EF indicates which services are allocated, and whether, if allocated, the service is activated. If a service is not 
allocated or not activated in the SIM, the ME shall not select this service. 



Identifier: '6F38' Structure: transparent Mandatory 


File size: X bytes, X • 2 Update activity: low 


Access Conditions: 

READ CHV1 
UPDATE ADM 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1 


Services n°1 to n°4 


M 


1 byte 


2 


Services n°5to n°8 


M 


1 byte 


3 


Services n°9 to n°12 





1 byte 


4 


Services n° 13 to n°16 





1 byte 


5 


Services n° 17 to n°20 





1 byte 


6 


Services n° 21 to n°24 





1 byte 


7 


Services n° 25 to n°28 





1 byte 


8 


Services n° 29 to n°32 





1 byte 


etc. 








X 


Services (4X-3) to (4X) 





1 byte 



Services 




Contents: Service n°1 : 


CHV1 disable function 


Service n°2 : 


Abbreviated Dialling Numbers (ADN) 


Service n°3 : 


Fixed Dialling Numbers (FDN) 


Service n°4 : 


Short Message Storage (SMS) 


Service n°5 : 


Advice of Charge (AoC) 


Service n°6 : 


Capability Configuration Parameters (CCP) 


Service n°7 : 


PLMN selector 


Service n°8 : 


RFU 


Service n°9 : 


MSISDN 


Service n°10 


Extensioni 


Service n°11 


Extension2 


Service n°12 


SMS Parameters 


Service n°13 


Last Number Dialled (LND) 


Service n°14 


Cell Broadcast Message Identifier 


Service n°15 


Group Identifier Level 1 


Service n°16 


Group Identifier Level 2 


Service n°17 


Service Provider Name 


Service n°18 


Service Dialling Numbers (SON) 


Service n°1 9 


Extensions 


Service n°20 


RFU 


Service n°21 


VGCS Group Identifier List (EF^QQg and EF^QQgs) 


Service n°22 


VBS Group Identifier List (EF^bs a"d EF^bss) 


Service n°23 


enhanced Multi-Level Precedence and Pre-emption Service 


Service n°24 


Automatic Answer for eMLPP 


Service n°25 


Data download via SMS-CB 


Service n°26 


Data download via SMS-PP 


Service n°27 


Menu selection 


Service n°28 


Call control 


Service n°29 


Proactive SIM 


Service n°30 


Cell Broadcast Message Identifier Ranges 


Service n°31 


Barred Dialling Numbers (BDN) 


Service n°32 


Extension4 


Service n°33 


De-personalization Control Keys 


Service n°34 


Co-operative Network List 


Service n°35 


Short Message Status Reports 


Service n°36 


Network's indication of alerting in the MS 


Service n°37 


Mobile Originated Short Message control by SIM 


Service n°38 


GPRS 


Service n°39 


Image (IMG) 


Service n°40 


SoLSA (Support of Local Service Area) 


Service n°41 


USSD string data object supported in Call Control 


Service n°42 


RUN AT COMMAND command 
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For a phase 2 SIM, the EF shall contain at least two bytes which correspond to the Phase 1 services. Further bytes may 
be included, but if the EF includes an optional byte, then it is mandatory for the EF to also contain all bytes before that 
byte. Other services are possible in the future and will be coded on further bytes in the EF. The coding falls under the 
responsibihty of ETSI. 

NOTE 1: Service N°8 was used in Phase 1 for Called Party Subaddress. To prevent any risk of incompatibility 
Service N°8 should not be reallocated. 

NOTE 2: As the BDN service relies on the Call Control feature, service n°31 (BDN) should only be allocated and 
activated if service n°28 (Call control) is allocated and activated. 

Coding: 

2 bits are used to code each service: 
first bit = 1 : service allocated 
first bit = 0: service not allocated 

where the first bit is bl, b3, b5 or b7; 
second bit = 1 : service activated 
second bit = 0: service not activated 

where the second bit is b2, b4, b6 or bS. 

Service allocated means that the SIM has the capability to support the service. Service activated means that 
the service is available for the card holder (only valid if the service is allocated). 

The following codings are possible: 

first bit = 0: service not allocated, second bit has no meaning; 
first bit = 1 and second bit = 0: service allocated but not activated; 
first bit = 1 and second bit = 1 : service allocated and activated. 

The bits for services not yet defined shall be set to RFU. For coding of RFU see subclause 9.3. 
First byte: 





b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 


Service 
Service 
























L 


-^ 


n°l 
n°2 














Service 


n°3 


















Service 


n°4 


Seco 


nc 


byte: 














Service 
Service 






b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 
























L 


-^ 


n°5 
n°6 














Service 


n°7 






















Service 


n°8 



etc. 

The following example of coding for the first byte means that service n°l "CHVl-Disabling" is allocated but 
not activated: 



bS 


b7 


b6 


b5 


b4 


b3 


b2 


bl 


1 
X 


1 
X 


1 
X 


1 
X 


1 
X 


1 
X 


1 




1 

1 



If the SIM supports the FDN feature (FDN allocated and activated) a special mechanism shall exist in the SIM which 
invalidates both EFjj^^gj and EFjjy^^ once during each GSM session. This mechanism shall be invoked by the SIM 
automatically if FDN is enabled. This invalidation shall occur at least before the next command following selection of 
either EF. FDN is enabled when the ADN is invalidated or not activated. 

If the SIM supports the BDN feature (BDN allocated and activated) a special mechanism shall exist in the SIM which 
invalidates both EFjjyj^j and EFlqci once during each GSM session and which forbids the REHABILITATE command 
to rehabilitate both EFjj^^j and EFlq(;;j until the PROFILE DOWNLOAD procedure is performed indicating that the 
ME supports the "Call control by SIM" facility. This mechanism shall be invoked by the SIM automatically if BDN is 
enabled. The invalidation of EFjjyj^j and EF^j^^i shall occur at least before the next command following selection of 
either EF. BDN is enabled when the EFg^j,^ is not invalidated. 
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10.3.8 EF^cM (Accumulated call meter) 

This EF contains the total number of units for both the current call and the preceding calls. 

NOTE: The information may be used to provide an indication to the user for advice or as a basis for the 
calculation of the monetary cost of calls (see GSM 02.86 [9]). 



Identifier: '6F39' Structure: cyclic Optional 


Record length: 3 bytes Update activity: high 


Access Conditions: 

READ CHV1 
UPDATE CHV1/CHV2 

(fixed during administrative management) 
INCREASE CHV1 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1 -3 


Accumulated count of units 


M 


3 bytes 



Accumulated count of units 
Contents: value of the ACM 
Coding: see the coding of EF^qj^j^jj^^ 



1 0.3.9 EFg,di (Group Identifier Level 1 ) 



This EF contains identifiers for particular SIM -ME associations. It can be used to identify a group of SIMs for a 
particular application. 



Identifier: '6F3E' Structure: transparent Optional 


File size: 1 -n bytes Update activity: low 


Access Conditions: 

READ CHV1 
UPDATE ADM 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1 -n 


SIM group identifier(s) 





n bytes 



1 0.3. 1 EFg,d2 (Group Identifier Level 2) 



This EF contains identifiers for particular SIM -ME associations. It can be used to identify a group of SIMs for a 
particular application. 



Identifier: '6F3F' Structure: transparent Optional 


File size: 1 -n bytes Update activity: low 


Access Conditions: 

READ CHV1 
UPDATE ADM 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1 -n 


SIM group identifier(s) 





n bytes 



NOTE: The structure of EFqjj-,j and EFqjj-,2 are identical. They are provided to allow the network operator to 
enforce different levels of security dependant on application. 
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1 0.3. 1 1 EFgpN (Service Provider Name) 

This EF contains the service provider name and appropriate requirements for the display by the ME. 



Identifier: '6F46' Structure: transparent Optional 


File Size: 1 7 bytes Update activity: low 


Access Conditions: 

READ ALWAYS 
UPDATE ADM 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1 


Display Condition 


M 


1 byte 


2-17 


Service Provider Name 


M 


1 6 bytes 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 

























































Display Condition 

Contents: display condition for the service provider name in respect to the registered PLMN (see 
GSM 02.07 [3]). 

Coding: see below 
Byte 1: 



bl=0 ; display of registered PLMN not required 
bl=l ; display of registered PLMN required 
RFU (see subclause 9.3) 



Service Provider Name 

Contents: service provider string to be displayed 
Coding: the string shall use either 

- the SMS default 7-bit coded alphabet as defined in GSM 03.38 [12] with bit 8 set to 0. The string shall be left 
justified. Unused bytes shall be set to 'FF'. 
or 

one of the UCS2 code options defined in Annex B. 

1 0.3. 1 2 EFpucT (Price per unit and currency table) 

This EF contains the Price per Unit and Currency Table (PUCT). The PUCT is Advice of Charge related information 
which may be used by the ME in conjunction with EF^(-.]y[ to compute the cost of calls in the currency chosen by the 
subscriber, as specified in GSM 02.24 [7]. This EF shall always be allocated if EF^f^jyj is allocated. 



Identifier: '6F41' Structure: transparent Optional 


File size: 5 bytes Update activity: low 


Access Conditions: 

READ CHV1 
UPDATE CHV1/CHV2 

(fixed during administrative management) 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1 -3 


Currency code 


M 


3 bytes 


4-5 


Price per unit 


M 


2 bytes 



Currency code 

Contents: 

the alpha-identifier of the currency code. 

Coding: 

bytes 1, 2 and 3 are the respective first, second and third character of the alpha identifier. This alpha-tagging 
shall use the SMS default 7-bit coded alphabet as defined in GSM 03.38 [12] with bit 8 set to 0. 
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Price per unit 

Contents: 

price per unit expressed in the currency coded by bytes 1-3. 

Coding: 

Byte 4 and bits bl to b4 of byte 5 represent the Elementary Price per Unit (EPPU) in the currency coded by 
bytes 1 -3 . Bits b5 to b8 of byte 5 are the decimal logarithm of the multiplicative factor represented by the 
absolute value of its decimal logarithm (EX) and the sign of EX, which is coded for a positive sign and 1 
for a negative sign. 

Byte 4: 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 


1 


1 


1 


1 


1 


1 


1 


1 



2^ of EPPU 



Byte 5: 



b7 b6 b5 b4 b3 b2 bl 



T — — I — — I — — r 

,3 oz ,1 



2^ 2^ 2^ 



2^ of EPPU 



Sign of EX 



2° of Abs (EX) 
"2^ of Abs (EX) 
"2^ of Abs (EX) 



The computation of the price per unit value is made by the ME in compliance with GSM 02.24 [7] by the 
following formula: 

price per unit = EPPU * 10^^. 

The price has to be understood as expressed in the coded currency. 

1 0.3. 1 3 EFcBMi (Cell broadcast message identifier selection) 

This EF contains the Message Identifier Parameters which specify the type of content of the cell broadcast messages that 
the subscriber wishes the MS to accept. 

Any number of CB Message Identifier Parameters may be stored in the SIM. No order of priority is applicable. 



Identifier: '6F45' Structure: transparent 


Optional 


File size: 2n bytes Update activity 


: low 


Access Conditions: 

READ CHV1 
UPDATE CHV1 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1 -2 


CB Message Identifier 1 





2 bytes 


3-4 


CB Message Identifier 2 





2 bytes 










2n-1 - 2n 


CB Message Identifier n 





2 bytes 



Cell Broadcast Message Identifier 
Coding: 

as in GSM 03.41, "Message Format on BTS-MS Interface - Message Identifier". 

Values listed show the types of message which shall be accepted by the MS. 

Unused entries shall be set to 'FF FF'. 
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1 0.3. 1 4 EFbcch (Broadcast control channels) 

This EF contains information concerning the BCCH according to GSM 04.08 [15]. 

BCCH storage may reduce the extent of a Mobile Station's search of BCCH carriers when selecting a cell. The BCCH 
carrier lists in an MS shall be in accordance with the procedures specified in GSM 04.08 [15]. The MS shall only store 
BCCH information from the System Information 2 message and not the 2bis extension message. 



Identifier: '6F74' 


Structure 


transparent Mandatory 


File size: 16 bytes 




Update activity: high 


Access Conditions: 
READ 
UPDATE 
INVALIDATE 
REHABILITATE 


CHV1 
CHV1 
ADM 
ADM 




Bytes 


Description 


M/0 


Length 


1 -16 


BCCH information 


M 


16 bytes 



BCCH information 
Coding: 

The information is coded as octets 2-17 of the "neighbour cells description information element" in 

GSM 04.08 [15]. 



1 0.3. 1 5 EF^cc (Access control class) 



This EF contains the assigned access control class(es). GSM 02.1 1 [5] refers. The access control class is a parameter to 
control the RACH utilization. 15 classes are split into 10 classes randomly allocated to normal subscribers and 5 classes 
allocated to specific high priority users. For more information see GSM 02.1 1 [5]. 



Identifier: '6F78' Structure: transparent Mandatory 


File size: 2 bytes Update activity: low 


Access Conditions: 

READ CHV1 
UPDATE ADM 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1 -2 


Access control classes 


M 


2 bytes 



Access control classes 
Coding: 

Each ACC is coded on one bit. An ACC is "allocated" if the corresponding bit is set to 1 and "not allocated" 

if this bit is set to 0. Bit b3 of byte 1 is set to 0. 

Byte 1: 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 


1 


1 


1 


1 


1 


1 


1 


1 



15 14 13 12 11 10 09 08 Number of the ACC (except for bit b3) 



Byte 2: 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 


1 


1 


1 


1 


1 


1 


1 


1 



07 Of 



05 04 03 02 01 00 Number of the ACC 
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10.3.16 EF 



FPLMN 



(Forbidden PLMNs) 



This EF contains the coding for four Forbidden PLMNs (FPLMN). It is read by the ME as part of the SIM initialization 
procedure and indicates PLMNs which the MS shall not automatically attempt to access. 

A PLMN is written to the EF if a network rejects a Location Update with the cause "PLMN not allowed". The ME shall 
manage the list as follows. 

When four FPLMNs are held in the EF, and rejection of a further PLMN is received by the ME from the network, the 
ME shall modify the EF using the UPDATE command. This new PLMN shall be stored in the fourth position, and the 
existing list "shifted" causing the previous contents of the first position to be lost. 

When less than four FPLMNs exist in the EF, storage of an additional FPLMN shall not cause any existing FPLMN to 
be lost. 

Dependent upon procedures used to manage storage and deletion of FPLMNs in the EF, it is possible, when less than 
four FPLMNs exist in the EF, for 'FFFFFF' to occur in any position. The ME shall analyse all the EF for FPLMNs in 
any position, and not regard 'FFFFFF' as a termination of valid data. 



Identifier: '6F7B' 


Structure: transparent 


Mandatory 


File size: 12 bytes 


Update activity 


: low 


Access Conditions: 
READ 
UPDATE 
INVALIDATE 
REHABILITATE 


CHV1 
CHV1 
ADM 
ADM 




Bytes 


Description 


M/0 


Length 


1 -3 


PLMN 1 


M 


3 bytes 


4-6 


PLMN 2 


M 


3 bytes 


7-9 


PLMNS 


M 


3 bytes 


10- 12 


PLMN 4 


M 


3 bytes 



- PLMN 
Contents: 

Mobile Country Code (MCC) followed by the Mobile Network Code (MNC). 
Coding: 

according to GSM 04.08 [15]. 

For instance, using 246 for the MCC and 81 for the MNC and if this is stored in PLMN 3 the contents is as 

follows: 

Bytes 7-9: '42"F6" 18' 
If storage for fewer than 4 PLMNs is required, the unused bytes shall be set to 'FF. 

10.3.17 EFloci (Location information) 

This EF contains the following Location Information: 

Temporary Mobile Subscriber Identity (TMSI) 
Location Area Information (LAI) 

- TMSI TIME 

- Location update status 
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Identifier: '6F7E' Structure: transparent Mandatory 


File size: 1 1 bytes Update activity: high 


Access Conditions: 

READ CHV1 
UPDATE CHV1 
INVALIDATE ADM 
REHABILITATE CHV1 


Bytes 


Description 


M/0 


Length 


1 -4 


TMSI 


M 


4 bytes 


5-9 


LAI 


M 


5 bytes 


10 


TMSI TIME 


M 


1 byte 


11 


Location update status 


M 


1 byte 



TMSI 

Contents: Temporary Mobile Subscriber Identity 

Coding: according to GSM 04.08 [15]. 

Byte 1: first byte of TMSI 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 


1 


1 


1 


1 


1 


1 


1 


1 



LAI 

Contents: Location Area Information 

Coding: according to GSM 04.08 [15]. 

Byte 5: first byte of LAI (MCC) 



b7 b6 b5 b4 b3 b2 bl 



LSB of MCC Digit 1 



MSB of MCC Digit 1 
"lSB of MCC Digit 2 



MSB of MCC Digit 2 



Byte 6: second byte of LAI (MCC continued) 



b7 



b6 



b5 



b4 



b3 



b2 



bl 



LSB of MCC Digit 3 



MSB of MCC Digit 3 
bits b5 to b8 are 1 



Byte 7: third byte of LAI (MNC) 



b7 



b6 



b5 



b4 



b3 



b2 



bl 



Byte 8: fourth byte of LAI (LAC) 

Byte 9: fifth byte of LAI (LAC continued) 



LSB of MNC Digit 1 



MSB of MNC Digit 1 
"lSB of MNC Digit 2 



MSB of MNC Digit 2 
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TMSI TIME 

Contents: Current value of Periodic Location Updating Timer (T3212). 

This byte is used by Phase 1 MEs, but it shall not be used by Phase 2 MEs. 



Location update 


status 










Contents: status of location 


upd; 


ite according 


to GSM 04.08 [15]. 


Coding: 












Byte 11: 












Bits: 






b3 


b2 


bl 















updated 












1 


not updated 









1 





PLMN not allowed 









1 


1 


Location Area not allowed 


1 






1 


1 


reserved 



Bits b4 to b8 are RFU (see subclause 9.3). 

1 0.3. 1 8 EF^D (Administrative data) 

This EF contains information concerning the mode of operation according to the type of SIM, such as normal (to be 
used by PLMN subscribers for GSM operations), type approval (to allow specific use of the ME during type approval 
procedures of e.g. the radio equipment), cell testing (to allow testing of a cell before commercial use of this cell), 
manufacturer specific (to allow the ME manufacturer to perform specific proprietary auto-test in its ME during e.g. 
maintenance phases). 

It also provides an indication of whether some ME features should be activated during normal operation. 



Identifier: '6FAD' Structure: transparent 


Mandatory 


File size: 3+X bytes Update activity 


: low 


Access Conditions: 

READ ALW 
UPDATE ADM 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1 


MS operation mode 


M 


1 byte 


2-3 


Additional information 


M 


2 bytes 


4 -3+X 


RFU 





X bytes 



MS operation mode 

Contents: mode of operation for the MS 

Coding: 

Initial value 

- normal operation '00' 

- type approval operations '80' 

- normal operation + specific facilities '01' 

- type approval operations + specific facilities '81' 

- maintenance (off line) '02' 

- cell test operation '04' 

Additional information 
Coding: 

- specific facilities (if bl=l in byte 1); 

Byte 2 (first byte of additional information): 



b7 



b6 



b5 



b4 



b3 



b2 



bl 



RFU 
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Byte 3: 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 

























































bl=0: OFM to be disabled by the ME 
bl=l: OFM to be activated by the ME 
RFU 



ME manufacturer specific information (if b2=l in byte 1). 



10.3.19 EF 



Phase 



(Phase identification) 



This EF contains information concerning the phase of the SIM. 



Identifier: '6FAE' Structure: transparent Mandatory 


File size: 1 byte Update activity: low 


Access Conditions: 

READ ALW 
UPDATE ADM 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1 


SIM Phase 


M 


1 byte 



- SIM Phase 
Coding: 

'00' : phase 1 
'02' : phase 2 
'03' : phase 2 and PROFILE DOWNLOAD required (see GSM IL 14 [27]). 

All other codings are reserved for specification by ETSI TC SMG. Codings '04' to 'OF' indicate that the SIM 
supports, as a minimum, the mandatory requirements defined in this specification. 

This phase identification does not preclude a SIM to support some features of a phase later than the one indicated in 
EPphase- P^'" example : if EFpjj^^g is coded '00', it may be assumed by the ME that some Phase 2 or Phase 2+ features are 
supported by this SIM; if EFpjj^j.g is coded '02' or '03', it may be assumed by the ME that some Phase 2+ features are 
supported by this SIM. 

However, the services n°3 (FDN) and/or n°5 (AoC) shall only be allocated and activated in SIMs of phase 2 or later 
with EFp[jjjj,g being coded '02' or greater. Similarly, service n°31 (BDN) shall only be allocated and activated in SIMs 
with EFp^^^g being coded '03' or greater. 

If EFp[j^j,g is coded '03' or greater, an ME supporting SIM Application Toolkit shall perform the PROFILE 
DOWNLOAD procedure, as defined in GSM 11. 14 [27]. 



10.3.20 EFvGcs (Voice Group Call Service) 



This EF contains a list of those VGCS group identifiers the user has subscribed to. The elementary file is used by the 
ME for group call establishment and group call reception. 
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Identifier: '6FB1' 


Structure: transparent 


Optional 


File size: 4n bytes (n <= 


50) Update activity 


: low 


Access Conditions: 
READ 
UPDATE 
INVALIDATE 
REHABILITATE 


CHV1 
ADM 
ADM 
ADM 




Bytes 


Description 


M/0 


Length 


1 -4 


Group ID 1 


M 


4 bytes 


5-8 


Group ID 2 





4 bytes 










(4n-3)-4n 


Group ID n 





4 bytes 



- Group ID 

Contents: VGCS Group Id 

Coding: according to GSM 03.03 [10] 

If storage for fewer than the maximum possible number of n is required, the excess bytes shall be set to 'FF'. 

1 0.3.21 EFvGcss (Voice Group Call Service Status) 

This EF contains the status of activation for the VGCS group identifiers. The elementary file is directly related to the 
EFyQf^g. This EF shall always be allocated if EFyq(;;§ is allocated. 



Identifier: '6FB2' Structure: transparent Optional 


File size: 7 bytes Update activity: low 


Access Conditions: 

READ CHV1 
UPDATE ADM 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1 -7 


Activation/Deactivation Flags 


M 


7 bytes 



Activation/Deactivation Flags 

Contents: Activation/Deactivation Flags of the appropriate Group IDs 

Coding: 

bit = means - Group ID deactivated 

bit = 1 means - Group ID activated 

Byte 1: 



b7 



b6 



b5 



b4 



b3 



b2 



bl 



Group ID 1 



Group ID 



etc 
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Byte 7: 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 
































L 


Group ID 4 9 
Group ID 50 










b3=l 












b4=l 














b5=l 
















b6=l 


















b7=l 




















b8=l 



1 0.3.22 EFvBs (Voice Broadcast Service) 

This EF contains a list of those VBS group identifiers the user has subscribed to. The elementary file is used by the ME 
for broadcast call establishment and broadcast call reception. 



Identifier: '6FB3' 


Structure: transparent 


Optional 


File size: 4n bytes (n <= 


50) Update activity 


: low 


Access Conditions: 
READ 
UPDATE 
INVALIDATE 
REHABILITATE 


CHV1 
ADM 
ADM 
ADM 




Bytes 


Description 


M/0 


Length 


1 -4 


Group ID 1 


M 


4 bytes 


5-2 


Group ID 2 





4 bytes 










{4n-3)-4n 


Group ID n 





4 bytes 



- Group ID 

Contents: VBS Group Id 

Coding: according to GSM 03.03 [10] 

If storage for fewer than the maximum possible number of n is required, the excess bytes shall be set to 'FF'. 

10.3.23 EFvBss (Voice Broadcast Service Status) 

This EF contains the status of activation for the VBS group identifiers. The elementary file is directly related to the 
EFygg. This EF shall always be allocated if EFygg is allocated. 



Identifier: '6FB4' Structure: transparent Optional 


File size: 7 bytes Update activity: low 


Access Conditions: 

READ CHV1 
UPDATE ADM 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1 -7 


Activation/Deactivation Flags 


M 


7 bytes 



Activation/Deactivation Flags 

Contents: Activation/Deactivation Flags of the appropriate Group IDs 

Coding: 

see coding of EFyQ^^^ 

10.3.24 EFgiyiLPP (eninanced Multi Level Pre-emption and Priority) 

This EF contains information about priority levels and fast call set-up conditions for the enhanced Multi Level Pre- 
emption and Priority service that which can be used by the subscriber. 
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Identifier: '6FB5' Structure: transparent Optional 


File size: 2 bytes Update activity: low 


Access Conditions: 

READ CHV1 
UPDATE ADM 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1 


Priority levels 


M 


1 byte 


2 


Fast call set-up conditions 


M 


1 byte 



Priority levels 

Contents: The eMLPP priority levels subscribed to. 

Coding: Each eMLPP priority level is coded on one bit. Priority levels subscribed to have their corresponding 

bits set to 1 . Priority levels not subscribed to have their corresponding bits set to 0. Bit b8 is reserved and set 

toO. 

Byte 1: 



b7 b6 b5 b4 b3 b2 bl 



priority level A 

priority level B 

priority level 

priority level 1 

priority level 2 

priority level 3 

priority level 4 

"o 



Example: If priority levels B and 2 are subscribed to, EFgjyj^pp shall be coded '12'. 

Fast call set-up conditions 

Contents: For each eMLPP priority level, the capability to use a fast call set-up procedure. 

Coding: Each eMLPP priority level is coded on one bit. Priority levels for which fast call set-up is allowed have 

their corresponding bits set to 1 . Priority levels for which fast call set-up is not allowed have their 

corresponding bits set to 0. Bit b8 is reserved and set to 0. 

Byte 2: fast call set-up condition for: 



b7 b6 b5 b4 b3 b2 bl 



fast call set-up condition for priority level A 

fast call set-up condition for priority level B 

fast call set-up condition for priority level 

fast call set-up condition for priority level 1 

fast call set-up condition for priority level 2 

fast call set-up condition for priority level 3 

fast call set-up condition for priority level 4 

'o 



Example: If fast call set-up is allowed for priority levels B, and 2, then byte 2 of EFgjyjLpp is coded '16'. 

1 0.3.25 EF^AeM (Automatic Answer for eMLPP Service) 

This EF contains those priority levels (of the Multi Level Pre-emption and Priority service) for which the mobile station 
shall answer automatically to incoming calls. 
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Identifier: '6FB6' Structure: transparent Optional 


File size: 1 byte Update activity: low 


Access Conditions: 

READ CHV1 
UPDATE CHV1 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1 


Automatic answer priority levels 


M 


1 byte 



Automatic answer priority levels 

Contents: 

For each eMLPP priority level, the capability for the mobile station to answer automatically to incoming calls 
(with the corresponding eMLPP priority level). 

Coding: 

Each eMLPP priority level is coded on one bit. Priority levels allowing an automatic answer from the mobile 
station have their corresponding bits set to 1 . Priority levels not allowing an automatic answer from the 
mobile station have their corresponding bits set to 0. Bit b8 is reserved and set to 0. 
Byte 1: 



b7 b6 b5 b4 b3 b2 bl 



Automatic answer priority for priority level A 

Automatic answer priority for priority level B 

Automatic answer priority for priority level 

Automatic answer priority for priority level 1 

Automatic answer priority for priority level 2 

Automatic answer priority for priority level 3 

Automatic answer priority for priority level 4 

"o 



Example: If automatic answer is allowed for incoming calls with priority levels A, and 1, then EF^^gjyf^pp is 
coded 'OD'. 

10.3.26 EFcBMiD (Cell Broadcast Message Identifier for Data Download) 

This EF contains the message identifier parameters which specify the type of content of the cell broadcast messages 
which are to be passed to the SIM. 

Any number of CB message identifier parameters may be stored in the SIM. No order of priority is applicable. 



Identifier: '6F48' Structure: transparent 


Optional 


File size: 2n bytes Update activity 


: low 


Access Conditions: 

READ CHV1 
UPDATE ADM 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1-2 


CB Message Identifier 1 





2 bytes 


3-4 


CB Message Identifier 2 





2 bytes 










2n-1-2n 


CB Message Identifier n 





2 bytes 



Cell Broadcast Message Identifier 
Coding: 

as in GSM 03.41 [14]. Values listed show the identifiers of messages which shall be accepted by the MS to 

be passed to the SIM. 

Unused entries shall be set to 'FF FF'. 
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10.3.27 EFecc (Emergency Call Codes) 

This EF contains up to 5 emergency call codes. 



Identifier: '6FB7' Structure: transparent Optional 


File size: 3n (n < 5) bytes Update activity: low 


Access Conditions: 

READ ALW 
UPDATE ADM 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1 -3 


Emergency Call Code 1 





3 bytes 


4-6 


Emergency Call Code 2 





3 bytes 










(3n-2) - 3n 


Emergency Call Code n 





3 bytes 



Emergency Call Code 
Contents: 

Emergency Call Code 
Coding: 

The emergency call code is of a variable length with a maximum length of 6 digits. Each emergency call code 

is coded on three bytes, with each digit within the code being coded on four bits as shown below. If a code of 

less that 6 digits is chosen, then the unused nibbles shall be set to 'F'. 

Byte 1: 



b7 b6 b5 b4 b3 b2 bl 



LSB of Digit 1 



MSB of Digit 1 
"lSB of Digit 2 



MSB of Digit 2 



Byte 2: 



b8 



b7 



b6 



b5 



b4 



b3 



b2 



bl 



LSB of Digit 3 



MSB of Digit 3 
"lSB of Digit 4 



MSB of Digit 4 



Byte 3: 



b7 



b6 



b5 



b4 



b3 



b2 



bl 



LSB of Digit 5 



MSB of Digit 5 
"lSB of Digit 6 



MSB of Digit 6 
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1 0.3.28 EFcBMiR (Cell broadcast message identifier range selection) 

This EF contains ranges of cell broadcast message identifiers that the subscriber wishes the MS to accept. 

Any number of CB Message Identifier Parameter ranges may be stored in the SIM. No order of priority is applicable. 



Identifier: '6F50' Structure: transparent Optional 


File size: 4n bytes Update activity: low 


Access Conditions: 

READ CHV1 
UPDATE CHV1 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1 -4 


CB Message Identifier Range 1 





4 bytes 


5-8 


CB Message Identifier Range 2 





4 bytes 










(4n-3) - 4n 


CB Message Identifier Range n 





4 bytes 



Cell Broadcast Message Identifier Ranges 

Contents: 

CB Message Identifier ranges: 

Coding: 

bytes one and two of each range identifier equal the lower value of a cell broadcast range, bytes three and 
four equal the upper value of a cell broadcast range, both values are coded as in GSM 03.41 [14] "Message 
Format on BTS-MS Interface - Message Identifier". Values listed show the ranges of messages which shall be 
accepted by the MS. 
Unused entries shall be set to 'FF FF FF FF'. 

10.3.29 EFdck De-personalization Control Keys 

This EF provides storage for the de-personalization control keys associated with the OTA de-personalization cycle of 
GSM 02.22. 



Identifier: '6F2C' Structure: transparent Optional 


File size: 16 bytes Update activity: low 


Access Conditions: 

READ CHV1 
UPDATE CHV1 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1 to 4 


8 digits of network de-personalization control 
key 


M 


4 bytes 


5 to 8 


8 digits of network subset de-personalization 
control key 


M 


4 bytes 


9 to 12 


8 digits of service provider de-personalization 
control key 


M 


4 bytes 


13to16 


8 digits of corporate de-personalization control 
key 


M 


4 bytes 



Empty control key records shall be coded 'FFFFFFFF'. 

10.3.30 EFcNL(Co-operative Network List) 

This EF contains the Co-operative Network List for the multiple network personalization services defined in 
GSM 02.22. 
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Identifier: '6F32' 


Structure 


transparent 




Optional 


File size: 6n bytes 




Update activity 


: low 


Access Conditions: 
READ 
UPDATE 
INVALIDATE 
REHABILITATE 


CHV1 
ADM 
ADM 
ADM 








Bytes 


Description 


M/0 


Length 


1 to 6 


Element 1 of co- 


operative net list 







6 bytes 




6n-5 to 6n 


Element n of co- 


operative net list 







6 bytes 



Co-operative Network List 
Contents: 

MCC, MNC, network subset, service provider ID and corporate ID of co-operative networks. 
Coding: 

For each 6 byte list element 

Byte 1: 



b7 



b6 



b5 



b4 



b3 



b2 



bl 



LS bit of MCC digit 1 



MS bit of MCC digit 1 
"lS bit of MCC digit 2 



MS bit of MCC digit 2 



Byte 2: 



b7 



b6 



b5 



b4 



b3 



b2 



bl 



LS bit of MCC digit 3 



MS bit of MCC digit 3 
"ls bit of MNC digit 3 



MS bit of MNC digit 3 



Byte 3: 



b7 



b6 



b5 



b4 



b3 



b2 



bl 



LS bit of MNC digit 1 



MS bit of MNC digit 1 
"ls bit of MNC digit 2 



MS bit of MNC digit 2 



Byte 4: 



b7 



b6 



b5 



b4 



b3 



b2 



bl 



LS bit of network subset digit 1 



MS bit of network subset digit 1 
LS bit of network subset digit 2 



MS bit of network subset digit 2 
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NOTE: Digit 3 of the MNC is placed directly after the MCC fields for compatibility between GSM and PCS 1900 
PLMN structures. 

Byte 5: 



b8 



b7 



b6 



b5 



b4 



b3 



b2 



bl 



LS bit of service provider digit 1 



MS bit of service provider digit 1 
LS bit of service provider digit 2 



MS bit of service provider digit 2 



Byte 6: 



b7 



b6 



b5 



b4 



b3 



b2 



bl 



LS bit of corporate digit 1 



MS bit of corporate digit 1 
LS bit of corporate digit 2 



MS bit of corporate digit 2 



For 2 digit MNCs digit 3 of this field shall be 'F'. 

For 1 digit network subsets digit 2 of this field shall be 0. 

Empty fields shall be coded with 'FF'. 

The end of the list is delimited by the first MCC field coded 'FEE'. 

10.3.31 EFNiA(Network's Indication of Alerting) 

This EE contains categories and associated text related to the Network's indication of alerting in the MS service defined 
in GSM 02.07 [3]. 



Identifier: '6F51' Structure: linear fixed Optional 


Record length : X+1 bytes Update activity: low 


Access Conditions: 

READ CHV1 
UPDATE ADM 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1 


Alerting category 


M 


1 byte 


2 to X+1 


Informative text 


M 


X bytes 



Alerting category 
Contents: 

category of alerting for terminating traffic. 
Coding: 

according to GSM 04.08 [15]. Value 'FF' means that no information on alerting category is available. 

Informative text 
Contents: 

text describing the type of terminating traffic associated with the category. 
Coding: 

see the coding of the Alpha Identifier item of the EF^pj^ (subclause 10.5. 1). The maximum number of 

characters for this informative text is indicated in GSM 02.07 [3]. 
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1 0.3.32 EFkcgprs (GPRS Ciphering key KcGPRS) 

This EF contains the ciphering key KcGPRS and the ciphering key sequence number n for GPRS (see GSM 03.60 [32]). 



Identifier: '6F52' 


Structure 


: transparent 


Mandatory 


File size: 9 bytes 




Update activity: high 


Access Conditions: 
READ 
UPDATE 
INVALIDATE 
REHABILITATE 


CHV1 
CHV1 
ADM 
ADM 






Bytes 


Description 


M/0 


Length 


1 -8 


Ciphering key KcGPRS 


M 


8 bytes 


9 


Ciphering key sequence number n 


for GPRS 


M 


1 byte 



Ciphering key KcGPRS 
Coding: 

The least significant bit of KcGPRS is the least significant bit of the eighth byte. The most significant bit of 

KcGPRS is the most significant bit of the first byte. 

Ciphering key sequence number n for GPRS 
Coding: 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 
















1 1 1 

























bits b4 to b8 are coded 

NOTE: GSM 04.08 [15] defines the value of n=l 1 1 as "key not available". Therefore the value '07' and not 'FF' 
should be present following the administrative phase. 

10.3.33 EFlocigprs (GPRS location information) 

This EF contains the following Location Information: 

Packet Temporary Mobile Subscriber Identity (P-TMSI) 

Packet Temporary Mobile Subscriber Identity signature value (P-TMSI signature value) 

Routing Area Information (RAI) 

Routing Area update status 



Identifier: '6F53' Structure: transparent Mandatory 


File size: 14 bytes Update activity: high 


Access Conditions: 

READ CHV1 
UPDATE CHV1 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1 -4 


P-TMSI 


M 


4 bytes 


5-7 


P-TMSI signature value 


M 


3 bytes 


8-13 


RAI 


M 


6 bytes 


14 


Routing Area update status 


M 


1 byte 



P-TMSI 

Contents: Packet Temporary Mobile Subscriber Identity 

Coding: according to GSM 04.08 [15]. 

Byte 1: first byte of P-TMSI 
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b8 hi b6 b5 b4 b3 b2 



bl 



~~i 1 1 1 1 1 1 r 

MSB 



P-TMSI signature value 

Contents: Packet Temporary Mobile Subscriber Identity signature value 

Coding: according to GSM 04.08 [15]. 

Byte 1 : first byte of P-TMSI signature value 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 


1 


1 


1 


1 


1 


1 


1 


1 



MSB 



RAI 

Contents: Routing Area Information 
Coding: according to GSM 04.08 [15]. 

Byte 5: first byte of RAI 



b7 b6 b5 b4 b3 b2 bl 



LSB of MCC Digit 1 



MSB of MCC Digit 1 
"lSB of MCC Digit 2 



MSB of MCC Digit 2 



Byte 6: second byte of RAI (MCC continued) 



b7 



b6 



b5 



b4 



b3 



b2 



bl 



LSB of MCC Digit 3 



MSB of MCC Digit 3 
bits b5 to b8 are 1 



Byte 7: third byte of RAI (MNC) 



b7 



b6 



b5 



b4 



b3 



b2 



bl 



LSB of MNC Digit 1 



MSB of MNC Digit 1 
"lSB of MNC Digit 2 



MSB of MNC Digit 2 



Byte 8: fourth byte of RAI (LAC) 
Byte 9: fifth byte of RAI (LAC continued) 
Byte 10: sixth byte of RAI (RAC)- Routing update status 

Contents: status of location update according to GSM 04.08 [15]. 
Coding: 
Byte 12: 

Bits: b3 b2 bl 

0: updated 
1 : not updated 
10: PLMN not allowed 
1 1 : Routing Area not allowed 
11 1 : reserved 
Bits b4 to b8 are RFU (see subclause 9.3). 
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10.3.34 EFguME (SetUpMenu Elements) 



This EF contains Simple TLVs related to the menu title to be used by a SIM card supporting the SIM API when 
issuing a SET UP MENU proactive command. 



Identifier: '6F54' Structure: transparent Optional 


File size: X+Y bytes Update activity: low 


Access Conditions: 

READ ADM 
UPDATE ADM 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1 -X 


Title Alpha Identifier 


M 


X bytes 


1 +x - X+Y 


Title Icon Identifier 





Y bytes 



Title Alpha Identifier 
Contents: 

this field contains the Alpha Identifier Simple TLV defining the menu title text. 
Coding: 

according to GSM 11.14 [27]. 

- Title Icon Identifier 
Contents: 

this field contains the Icon Identifier Simple TLV defining the menu title icon. 
Coding: 

according to GSM 11.14 [27]. 

If not present the field shall be set to 'FF'. 

Unused bytes of this file shall be set to 'FF'. 

1 0.4 Contents of DFs at the GSM application level 
1 0.4.1 Contents of files at the GSM SoLSA level 

This subclause specifies the EFs in the dedicated file DFjolsa- It only apphes if the SoLSA feature is supported (see 
GSM 03.73 [33]). 

The EFs contain information about the users subscribed local service areas. 
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10.4.1 .1 EFg^i (SoLSA Access Indicator) 

This EF contains the 'LSA only access indicator'. This EF shall always be allocated if DFsolsa is present. 

If the indicator is set, the network will prevent terminated and/or originated calls when the MS is camped in cells that 
are not included in the list of allowed LS As in EFsll- Emergency calls are, however, always allowed. 

The EF also contains a text string which may be displayed when the MS is out of the served area(s). 



Identifier: '4F30' Structure: transparent Optional 


File size: X + 1 bytes Update activity: low 


Access Conditions: 

READ CHV1 
UPDATE ADM 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1 


LSA only access indicator 


M 


1 byte 


2 to X+1 


LSA only access indication text 


M 


X bytes 



LSA only access indicator 

Contents: indicates whether the MS is restricted to use LSA cells only or not. 

Coding: 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 

























































bl=0 ; LSA only access not activated 
bl=l: LSA only access activated 
RFU 

LSA only access indication text 

Contents: text to be displayed by the ME when it's out of LSA area. 

Coding: the string shall use either 

- the SMS default 7-bit coded alphabet as defined in GSM 03.38 [12] with bit 8 set to 0. The alpha identifier 

shall be left justified. Unused bytes shall be set to 'FF', 
or, 

one of the UCS2 coded options as defined in Annex B. 

10.4.1.2 EFsLL (SoLSA LSA List) 

This EF contains information describing the LSAs that the user is subscribed to. This EF shall always be allocated if 
DFsoLSA is present. 

Each LSA is described by one record that is linked to a LSA Descriptor file. Each record contains information of the 
PLMN, priority of the LSA, information about the subscription and may also contain a text string and/or an icon that 
identifies the LSA to the user. The text string can be edited by the user. 
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Identifier: '4F31' Structure: linear fixed Optional 


Record length: X + 10 bytes Update activity: low 


Access Conditions: 

READ CHV1 
UPDATE CHV1 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1 toX 


LSA name 





X bytes 


X+1 


Configuration parameters 


M 


1 byte 


X+2 


RFU 


M 


1 byte 


X+3 


Icon Identifier 


M 


1 byte 


X+4 


Priority 


M 


1 byte 


X+5 to X+7 


PLMN code 


M 


3 bytes 


X+8 to X+9 


LSA Descriptor File Identifier 


M 


2 byte 


X+10 


LSA Descriptor Record Identifier 


M 


1 byte 



LSA name 

Contents: LSA name string to be displayed when the ME is camped in the corresponding area, dependant on the 
contents of the LSA indication for idle mode field. 

Coding: the string shall use either 

- the SMS default 7-bit coded alphabet as defined in GSM 03.38 [12] with bit 8 set to 0. The alpha 

identifier shall be left justified. Unused bytes shall be set to 'FF', 
or 

one of the UCS2 coded options as defined in Annex B. 

Configuration parameters 

Contents: Icon qualifier, control of idle mode support and control of LSA indication for idle mode. 

Coding: 



b7 



b6 



b5 



b4 



b3 



b2 



bl 



Icon qualifier 

Idle mode support 

LSA indication for idle mode 

"rfu 



Icon qualifier: 

Contents: The icon qualifier indicates to the ME how the icon is to be used. 

b2, bl: 00: icon is not to be used and may not be present 

01: icon is self-explanatory, i.e. if displayed, it replaces the LSA name 

10: icon is not self-explanatory, i.e. if displayed, it shall be displayed together with the LSA name 

11: RFU 

Idle mode support: 

Contents: The idle mode support is used to indicate whether the ME shall favour camping on the LSA cells in 
idle mode. 

b3 = 0: Idle mode support disabled 
b3 = 1 : Idle mode support enabled 

LSA indication for idle mode: 

Contents: The LSA indication for idle mode is used to indicate whether or not the ME shall display the LSA 
name when the ME is camped on a cell within the LSA. 
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b4 = 0: LSA indication for idle mode disabled 
b4 = 1 : LSA indication for idle mode enabled 

Bits b5 to b8 are RFU (see subclause 9.3). 

Icon Identifier 

Contents: The icon identifier addresses a record in EFimg- 

Coding: binary. 

Priority 

Contents: Priority of the LSA which gives the ME the preference of this LSA relative to the other LSAs. 

Coding: binary. '00' is lowest priority 'FF' is highest. 

- PLMN code 

Contents: MCC + MNC for the LSA. 

Coding: according to GSM 04.08 [15] and EFloci- 

LSA Descriptor File Identifier: 

Contents: these bytes identify the EF which contains the LSA Descriptors forming the LSA. 

Coding: byte X+8: high byte of the LSA Descriptor file; 
byte X+9: low byte of the LSA Descriptor file. 

LSA Descriptor Record Identifier: 

Contents: this byte identifies the number of the first record in the LSA Descriptor file forming the LSA. 

Coding: binary. 

1 0.4.1 .3 LSA Descriptor files 

Residing under DFsolsa^ there may be several LSA Descriptor files. These EFs contains one or more records again 
containing LSA Descriptors forming the LSAs. LSAs can be described in four different ways. As a list of LSA IDs, as a 
list of LAC + CIs, as a list of CIs or as a Hst of LACs. As the basic elements (LSA ID, LAC + CI, CI and LAC) of the 
four types of lists are of different length, they can not be mixed within one record. Different records may contain 
different kinds of lists within the EFs. Examples of codings of LSA Descriptor files can be found in Annex H. 



Identifier: '4FXX' Structure: 


linear fixed 


Optional 


Record length: n*X+2 bytes 


Update activity 


: low 


Access Conditions: 

READ CHV1 
UPDATE ADM 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1 


LSA descriptor type and number 


M 


1 byte 


2 to X+1 


1" LSA Descriptor 


M 


X bytes 


X+2 to 2X+1 


2"° LSA Descriptor 


M 


X bytes 










(n-1)*X+2to 
n*X+1 


n'" LSA Descriptor 


M 


X bytes 


n*X+2 


Record Identifier 


M 


1 byte 



LSA descriptor type and number: 
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Contents: The LSA descriptor type gives the format of the LSA descriptor and the number of valid LSA 
Descriptors within the record. 

Coding: 

b8 I b7 I b6 I b5 I b4 I b3 I b2 I bl 

I I LSA descriptor type 

Number of LSA Descriptors 

LSA descriptor type: 

Contents: Gives the format of the LSA Descriptors. 

b2,bl: 00: LSA ID. 
01: LAC + CI 
10: CI 
11: LAC 

Number of LSA Descriptors: 

Contents: Gives the number of valid LSA Descriptors in the record. 

Coding: binary, with b8 as MSB and b3 as LSB leaving room for 64 LSA Descriptors per record. 

LSA Descriptor 

Contents: Dependant of the coding indicated in the LSA descriptor type: 

in case of LSA ID the field length 'X' is 3 bytes, 
- in case of LAC + CI the field length 'X' is 4 bytes, 

in case of CI the field length 'X' is 2 bytes, 

in case of LAC the field length 'X' is 2 bytes. 

Coding: according to GSM 04.08 [15]. 

Record Identifier: 

Contents: This byte identifies the number of the next record containing the LSA Descriptors forming the LSA. 

Coding: record number of next record. 'FF' identifies the end of the chain. 

This file utilises the concept of chaining as for EFexti. 

The identifier '4FXX' shall be different from one LSA Descriptor file to the other and different from the identifiers of 
EFg^ and EFgL^. For the range of 'XX', see subclause 6.6. 

1 0.5 Contents of files at the telecom level 

The EFs in the Dedicated File DFtelecom contain service related information. 

10.5.1 EF^DN (Abbreviated dialling numbers) 

This EF contains Abbreviated Dialling Numbers (ADN) and/or Supplementary Service Control strings (SSC). In 
addition it contains identifiers of associated network/bearer capabilities and identifiers of extension records. It may also 
contain an associated alpha-tagging. 
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Identifier: '6F3A' Structure: linear fixed 


Optional 


Record length: X+14 bytes Update activity 


low 


Access Conditions: 

READ CHV1 
UPDATE CHV1 
INVALIDATE CHV2 
REHABILITATE CHV2 


Bytes 


Description 


M/0 


Length 


1 toX 


Alpha Identifier 





X bytes 


X+1 


Length of BCD number/SSC contents 


M 


1 byte 


X+2 


TON and NPI 


M 


1 byte 


X+3toX+12 


Dialling Number/SSC String 


M 


1 bytes 


X+1 3 


Capability/Configuration Identifier 


M 


1 byte 


X+14 


Extensioni Record Identifier 


M 


1 byte 



Alpha Identifier 
Contents: 

Alpha-tagging of the associated dialling number. 
Coding: 

this alpha-tagging shall use either 

- the SMS default 7-bit coded alphabet as defined in GSM 03.38 [12] with bit 8 set to 0. The alpha 

identifier shall be left justified. Unused bytes shall be set to 'FF'. 
or 

one of the UCS2 coded options as defined in Annex B. 

NOTE 1 : The value of X may be from zero to 241 . Using the command GET RESPONSE the ME can determine 
the value of X. 

Length of BCD number/SSC contents 

Contents: 

this byte gives the number of bytes of the following two data items containing actual BCD number/SSC 
information. This means that the maximum value is 11, even when the actual ADN/SSC information length is 
greater than 11. When an ADN/SSC has extension, it is indicated by the extensioni identifier being unequal 
to 'FF'. The remainder is stored in the EFg^^i with the remaining length of the additional data being coded in 
the appropriate additional record itself (see subclause 10.5.10). 

Coding: 

according to GSM 04.08 [15]. 

- TON and NPI 

Contents: 

Type of number (TON) and numbering plan identification (NPI). 

Coding: 

according to GSM 04.08 [15]. If the Dialling Number/SSC String does not contain a dialling number, e.g. a 
control string deactivating a service, the TON/NPI byte shall be set to 'FF' by the ME (see note 2). 

NOTE 2: If a dialling number is absent, no TON/NPI byte is transmitted over the radio interface (see 

GSM 04.08 [15]). Accordingly, the ME should not interpret the value 'FF' and not send it over the radio 
interface. 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 
















1 


1 


1 


1 


NPI 












TON 




















1 



Dialling Number/SSC String 
Contents: 

up to 20 digits of the telephone number and/or SSC information. 
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Coding: 

according to GSM 04.08 [15] , GSM 02.30 [8] and the extended BCD-coding (see table 12). If the telephone 
number or SSC is longer than 20 digits, the first 20 digits are stored in this data item and the remainder is 
stored in an associated record in the EFg^jj. The record is identified by the Extensionl Record Identifier. If 
ADN/SSC require less than 20 digits, excess nibbles at the end of the data item shall be set to 'F'. Where 
individual dialled numbers, in one or more records, of less than 20 digits share a common appended digit 
string the first digits are stored in this data item and the common digits stored in an associated record in the 
EF^Xj^ ■ The record is identified by the Extension 1 Record Identifier. Excess nibbles at the end of the data 
item shall be set to 'F'. 



Byte X+3 



b7 



b6 



b5 b4 



b3 b2 



bl 



LSB of Digit 1 



MSB of Digit 1 
"lSB of Digit 2 



MSB of Digit 2 



Byte X+4: 



b7 



b6 



b5 



b4 



b3 



b2 



bl 



LSB of Digit 3 



MSB of Digit 3 
"lSB of Digit 4 



MSB of Digit 4 



etc. 

Capability/Configuration Identifier 
Contents: 

capability/configuration identification byte. This byte identifies the number of a record in the EF(;^(-;p 

containing associated capability/configuration parameters required for the call. The use of this byte is 

optional. If it is not used it shall be set to 'FF'. 
Coding: 

binary. 

- Extensionl Record Identifier 
Contents: 

extensionl record identification byte. This byte identifies the number of a record in the EFg^^i containing an 

associated called party subaddress or additional data. The use of this byte is optional. If it is not used it shall 

be set to 'FF'. 

If the ADN/SSC requires both additional data and called party subaddress, this byte identifies the additional 

record. A chaining mechanism inside EFg^xi identifies the record of the appropriate called party subaddress 

(see subclause 10.5.10). 
Coding: 

binary. 

NOTE 3: As EF^£,j,j is part of the DF-j-gLgj-.Qjyj it may be used by GSM and also other applications in a 

multi-application card. If the non-GSM application does not recognize the use of Type of Number (TON) 
and Number Plan Identification (NPI), then the information relating to the national dialling plan must be 
held within the data item dialling number/SSC and the TON and NPI fields set to UNKNOWN. This 
format would be acceptable for GSM operation and also for the non-GSM application where the TON and 
NPI fields shall be ignored. 
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Example: SIM storage of an International Number using E. 164 [19] numbering plan 

TON NPl Digit field 



GSM application 001 

Other application compatible with GSM 000 



0001 abc... 
0000 XXX.. .abc... 



where "abc..." denotes the subscriber number digits (including its country code), and "xxx..." 
denotes escape digits or a national prefix replacing TON and NPL 

NOTE 4: When the ME acts upon the EF^y-,f^ with a SEEK command in order to identify a character string in the 
alpha-identifier, it is the responsibility of the ME to ensure that the number of characters used as SEEK 
parameters are less than or equal to the value of X if the MMI allows the user to offer a greater number. 

Table 12: Extended BCD coding 



BCD Value 


Character/Meaning 


'0' 


"0" 






'9' 


"9" 


'A' 


11*11 


'B' 


"#" 


'C 


DTMF Control digit separator (GSM 02.07 [3]) 


'D' 


"Wild" value 

This will cause the IVIMI to prompt the user for a single digit (see 

GSM 02.07 [3]). 


'E' 


Expansion digit ("Shift Key"). 

It has the effect of adding '10' to the following digit. The following BCD digit 
will hence be interpreted in the range of '1 0'-'1 E'. The purpose of digits in 
this range is for further study. 


'F' 


Endmark 

e.g. in case of an odd number of digits 



BCD values 'C, 'D' and 'E' are never sent across the radio interface. 
NOTE 5: The interpretation of values 'D', 'E' and 'F' as DTMF digits is for further study. 
NOTE 6: A second or subsequent 'C BCD value will be interpreted as a 3 second PAUSE (see GSM 02.07 [3]). 



10.5.2 EFpDN (Fixed dialling numbers) 



This EF contains Fixed Dialling Numbers (FDN) and/or Supplementary Service Control strings (SSC). In addition it 
contains identifiers of associated network/bearer capabilities and identifiers of extension records. It may also contain an 
associated alpha-tagging. 



Identifier: '6F3B' Structure: linear fixed 


Optional 


Record length: X+14 bytes Update activity 


low 


Access Conditions: 

READ CHV1 
UPDATE CHV2 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/O 


Length 


1 toX 


Alpha Identifier 





X bytes 


X+1 


Length of BCD number/SSC contents 


M 


1 byte 


X+2 


TON and NPl 


M 


1 byte 


X+3toX+12 


Dialling Number/SSC String 


M 


10 bytes 


X+1 3 


Capability/Configuration Identifier 


M 


1 byte 


X+14 


Extension2 Record Identifier 


M 


1 byte 
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For contents and coding of all data items see the respective data items of the EF^pj^ (subclause 10.5. 1), with the 
exception that extension records are stored in the EFgxj2- 

NOTE: The value of X (the number of bytes in the alpha-identifier) may be different to the length denoted X in 



EF 



ADN- 



10.5.3 EFsMs (Short messages) 



This EF contains information in accordance with GSM 03.40 [13] comprising short messages (and associated 
parameters) which have either been received by the MS from the network, or are to be used as an MS originated 

message. 



Identifier: '6F3C' Structure: linear fixed Optional 


Record length: 176 bytes Update activity: low 


Access Conditions: 

READ CHV1 
UPDATE CHV1 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1 


Status 


M 


1 byte 


2 to 176 


Remainder 


M 


175 bytes 



Status 

Contents: 

Status byte of the record which can be used as a pattern in the SEEK command. For MS originating messages 
sent to the network, the status shall be updated when the MS receives a status report, or sends a successful 
SMS Command relating to the status report. 

Coding: 



b8 b7 b6 b5 b4 b3 b2 



bl 



free space 

1 used space 

1 message received by MS from network; message read 
1 message received by MS from network; message to be 

read 
1 MS originating message; message to be sent 

RFU (see subclause 9.3) 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 














1 

X 


1 

X 


1 

1 


1 




1 

1 




















1 





1 

















1 


1 





1 














1 





1 





1 














1 


1 


1 





1 



1 MS originating message; message sent to the network: 

status report not requested 

status report requested but not (yet) received; 

status report requested, received but not stored 

in EF-SMSR; 

status report requested, received and stored 

in EF-SMSR; 

RFU (see subclause 9.3) 



Remainder 
Contents: 

This data item commences with the TS-Service-Centre-Address as specified in GSM 04.11 [16]. The bytes 

immediately following the TS-Service-Centre- Address contain an appropriate short message TPDU as 

specified in GSM 03.40 [13], with identical coding and ordering of parameters. 
Coding: 

according to GSM 03.40 [13] and GSM 04.1 1 [16]. Any TP-message reference contained in an MS 

originated message stored in the SIM, shall have a value as follows: 



message to be sent: 



Value of the TP -message-reference: 
'FF' 
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message sent to the network: 



the value of TP-Message-Reference used in the 
message sent to the network. 



Any bytes in the record following the TPDU shall be filled with 'FF'. 

It is possible for a TS-Service-Centre- Address of maximum permitted length, e.g. containing more than 18 
address digits, to be associated with a maximum length TPDU such that their combined length is 176 bytes. In 
this case the ME shall store in the SIM the TS-Service-Centre-Address and the TPDU in bytes 2-176 without 
modification, except for the last byte of the TPDU, which shall not be stored. 

1 0.5.4 EFccp (Capability configuration parameters) 

This EF contains parameters of required network and bearer capabilities and ME configurations associated with a call 
established using an abbreviated dialling number, a fixed dialling number, an MSISDN, a last number dialled, a service 
dialling number or a barred dialling number. 



Identifier: '6F3D' Structure: linear fixed Optional 


Record length: 14 bytes Update activity: low 


Access Conditions: 

READ CHV1 
UPDATE CHV1 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1 to 10 


Bearer capability information element 


M 


10 bytes 


11 to 14 


Bytes reserved - see below 


M 


4 bytes 



Bearer capability information element 
Contents and Coding: 

see GSM 04.08 [15]. The Information Element Identity (lEI) shall be excluded, i.e. the first byte of the EFccp 

record shall be Length of the bearer capability contents. 

Bytes 11-14 shall be set to 'FF' and shall not be interpreted by the ME. 



10.5.5 EF 



MSISDN 



(MSISDN) 



This EF contains MSISDN(s) related to the subscriber. In addition it contains identifiers of associated network/bearer 
capabilities and identifiers of extension records. It may also contain an associated alpha-tagging. 



Identifier: '6F40' Structure: linear fixed Optional 


Record length: X+14 bytes Update activity: low 


Access Conditions: 

READ CHV1 
UPDATE CHV1 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1 toX 


Alpha Identifier 





X bytes 


X+1 


Length of BCD number/SSC contents 


M 


1 byte 


X+2 


TON and NPI 


M 


1 byte 


X+3toX+12 


Dialling Number/SSC String 


M 


1 bytes 


X+1 3 


Capability/Configuration Identifier 


M 


1 byte 


X+14 


Extensioni Record Identifier 


M 


1 byte 



For contents and coding of all data items see the respective data items of EF^j^j^. 

NOTE 1: If the SIM stores more than one MSISDN number and the ME displays the MSISDN number(s) within the 
initialization procedure then the one stored in the first record shall be displayed with priority. 
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NOTE 2: The value of X (the number of bytes in the alpha-identifier) may be different to the length denoted X in 



EF 



ADN- 



1 0.5.6 EFgiyisp (Short message service parameters) 

This EF contains values for Short Message Service header Parameters (SMSP), which can be used by the ME for user 
assistance in preparation of mobile originated short messages. For example, a service centre address will often be 
common to many short messages sent by the subscriber. 

The EF consists of one or more records, with each record able to hold a set of SMS parameters. The first (or only) 
record in the EF shall be used as a default set of parameters, if no other record is selected. 

To distinguish between records, an alpha-identifier may be included within each record, coded on Y bytes. 

The SMS parameters stored within a record may be present or absent independently. When a short message is to be sent 
from the MS, the parameter in the SIM record, if present, shall be used when a value is not supplied by the user. 



Identifier: '6F42' Structure: linear fixed 


Optional 


Record length: 28+Y bytes Update activity: 


low 


Access Conditions: 

READ CHV1 
UPDATE CHV1 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1 toY 


Alpha-Identifier 





Y bytes 


Y+1 


Parameter Indicators 


M 


1 byte 


Y+2toY+13 


TP-Destination Address 


M 


1 2 bytes 


Y+14toY+25 


TS-Service Centre Address 


M 


1 2 bytes 


Y+26 


TP-Protocol Identifier 


M 


1 byte 


Y+27 


TP-Data Coding Scheme 


M 


1 byte 


Y+28 


TP-Validity Period 


M 


1 byte 



Storage is allocated for all of the possible SMS parameters, regardless of whether they are present or absent. Any bytes 
unused, due to parameters not requiring all of the bytes, or due to absent parameters, shall be set to 'FF'. 

Alpha-Identifier 
Contents: 

Alpha Tag of the associated SMS -parameter. 
Coding: 

see subclause 10.5.1 (EF^qj^). 

NOTE: The value of Y may be zero, i.e. the alpha-identifier facility is not used. By using the command GET 
RESPONSE the ME can determine the value of Y. 

Parameter Indicators 
Contents: 

Each of the default SMS parameters which can be stored in the remainder of the record are marked absent or 

present by individual bits within this byte. 
Coding: 

Allocation of bits: 

Bit number Parameter indicated 

1 TP-Destination Address 

2 TS-Service Centre Address 

3 TP-Protocol Identifier 

4 TP-Data Coding Scheme 

5 TP-Validity Period 

6 reserved, set to 1 

7 reserved, set to 1 

8 reserved, set to 1 
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Bit value Meaning 

Parameter present 

1 Parameter absent 

TP-Destination Address 

Contents and Coding: As defined for SM-TL address fields in GSM 03.40 [13]. 

TP-Service Centre Address 

Contents and Coding: As defined for RP-Destination address Centre Address in GSM 04. 1 1 [16]. 

TP-Protocol Identifier 

Contents and Coding: As defined in GSM 03.40 [13]. 

TP-Data Coding Scheme 

Contents and Coding: As defined in GSM 03.38 [12]. 

- TP- Validity Period 

Contents and Coding: As defined in GSM 03.40 [13] for the relative time format. 

10.5.7 EFsMss (SMS status) 

This EF contains status information relating to the short message service. 

The provision of this EF is associated with EF^f^g. Both files shall be present together, or both absent from the SIM. 



Identifier: '6F43' Structure: transparent 


Optional 


File size: 2+X bytes Update activity 


: low 


Access Conditions: 

READ CHV1 
UPDATE CHV1 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1 


Last Used TP-MR 


M 


1 byte 


2 


SMS "Memory Cap. Exceeded" Not. Flag 


M 


1 byte 


3 to 2+X 


RFU 





X bytes 



Last Used TP-MR. 
Contents: 

the value of the TP-Message-Reference parameter in the last mobile originated short message, as defined in 

GSM 03.40 [13]. 
Coding: 

as defined in GSM 03.40 [13]. 

SMS "Memory Capacity Exceeded" Notification Flag. 
Contents: 

This flag is required to allow a process of flow control, so that as memory capacity in the MS becomes 

available, the Network can be informed. The process for this is described in GSM 03.40 [13]. 
Coding: 

bl=l means flag unset; memory capacity available 

bl=0 means flag set 

b2 to b8 are reserved and set to 1 . 
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1 0.5.8 EFlnd (Last number dialled) 



This EF contains the last numbers dialled (LND) and/or the respective supplementary service control strings (SSC). In 
addition it contains identifiers of associated network/bearer capabilities and identifiers of extension records. It may also 
contain associated alpha-tagging. 



Identifier: '6F44' Structure: cyclic 


Optional 


Record length: X+14 bytes Update activity 


low 


Access Conditions: 

READ CHV1 
UPDATE CHV1 
INCREASE NEVER 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1 toX 


Alpha Identifier 





X bytes 


X+1 


Length of BCD number/SSC contents 


M 


1 byte 


X+2 


TON and NPI 


M 


1 byte 


X+3toX+12 


Dialling Number/SSC String 


M 


1 bytes 


X+1 3 


Capability/Configuration Identifier 


M 


1 byte 


X+14 


Extensioni Record Identifier 


M 


1 byte 



For contents and coding, see subclause 10.5.1 EF^^j,^. 

The value of X in EF^nd ™^y be different to both the value of X in EF^^j,^ and of X in EFp^f^. 

If the value of X in EFlj,jj-, is longer than the length of the a-tag of the number to be stored, then the ME shall pad the 
a-tag with 'FF'. If the value of X in EFln^ is shorter than the length of the a-tag of the number to be stored, then the ME 
shall cut off excessive bytes. 

10.5.9 EFgoN (Service Dialling Numbers) 

This EF contains special service numbers (SDN) and/or the respective supplementary service control strings (SSC). In 
addition it contains identifiers of associated network/bearer capabilities and identifiers of extension records. It may also 
contain associated alpha-tagging. 



Identifier: '6F49' Structure: linear fixed Optional 


Record length: X+14 bytes Update activity: low 


Access Conditions: 

READ CHV1 
UPDATE ADM 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1-X 


Alpha identifier 





X bytes 


X+1 


Length of BCD number/SSC contents 


M 


1 bytes 


X+2 


TON and NPI 


M 


1 byte 


X+3-X+12 


Dialling Number/SSC String 


M 


10 bytes 


X+1 3 


Capability/Configuration Identifier 


M 


1 byte 


X+14 


Extensions Record Identifier 


M 


1 byte 



For contents and coding of all data items see the respective data items of the EF^pf^ (subclause 10.5. 1), with the 
exception that extension records are stored in the EFg^^s- 

NOTE: The value of X (the number of bytes in the alpha-identifier) may be different to the length denoted X in 



EF 



ADN- 
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10.5.10 EFexti (Extension 1) 

This EF contains extension data of an ADN/SSC, an MSISDN, or an LND. Extension data is caused by: 

- an ADN/SSC (MSISDN, LND) which is greater than the 20 digit capacity of the ADN/SSC (MSISDN, LND) 
Elementary File or where common digits are required to follow an ADN/SSC string of less than 20 digits. The 
remainder is stored in this EF as a record, which is identified by a specified identification byte inside the 
ADN/SSC (MSISDN, LND) Elementary File. The EXTl record in this case is specified as additional data; 

an associated called party subaddress. The EXTl record in this case is specified as subaddress data. 



Identifier: '6F4A' 


Structure: 


linear fixed 


Optional 


Record length: 13 bytes 


Update activity 


: low 


Access Conditions: 
READ 
UPDATE 
INVALIDATE 
REHABILITATE 


CHV1 
CHV1 
ADM 
ADM 






Bytes 


Description 


M/0 


Length 


1 


Record type 


M 


1 byte 


2 to 12 


Extension data 


M 


11 bytes 


13 


Identifier 


M 


1 byte 



Record type 

Contents: type of the record 

Coding: 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 






















L 


Called Party Subaddress 
Additional data 










RFU 



b3-b8 are reserved and set to 0; 

a bit set to 1 identifies the type of record; 

only one type can be set; 

'00' indicates the type "unknown". 

The following example of coding means that the type of extension data is "additional data": 



b8 


b7 


b6 


b5 


b4 


b3 


b2 


bl 


1 




1 




1 




1 




1 




1 




1 

1 


1 





Extension data 

Contents: Additional data or Called Party Subaddress depending on record type. 

Coding: 

Case 1, Extension! record is additional data: 

The first byte of the extension data gives the number of bytes of the remainder of ADN/SSC (respectively 
MSISDN, LND). The coding of remaining bytes is BCD, according to the coding of ADN/SSC 
(MSISDN, LND). Unused nibbles at the end have to be set to 'F'. It is possible if the number of additional 
digits exceeds the capacity of the additional record to chain another record inside the EXTl Elementary 
File by the identifier in byte 13. 
Case 2, Extension! record is Called Party Subaddress: 

The subaddress data contains information as defined for this purpose in GSM 04.08 [15]. All information 
defined in GSM 04.08, except the information element identifier, shall be stored in the SIM. The length of 
this subaddress data can be up to 22 bytes. In those cases where two extension records are needed, these 
records are chained by the identifier field. The extension record containing the first part of the called party 
subaddress points to the record which contains the second part of the subaddress. 

Identifier 

Contents: identifier of the next extension record to enable storage of information longer than 1 1 bytes. 

Coding: record number of next record. 'FF' identifies the end of the chain. 
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Example of a chain of extension records being associated to an ADN/SSC. The extensionl record identifier (Byte 
14+X) of ADN/SSC is set to 3. 



No of Record 



Type 



Extension Data 



Next 



Record 



Record 3 
Record 4 
Record 5 
Record 6 



'02' 
'xx' 
'01' 
'01' 



XX XX 

XX XX 

XX XX 

XX XX 



'06' ►- 
'xx' 

•FF' -*- 

'05' -<- 



In this example ADN/SSC is associated to additional data (record 3) and a called party subaddress whose length 
is more than 1 1 bytes (records 6 and 5). 



1 0.5. 1 1 EFext2 (Extension2) 

This EF contains extension data of an FDN/SSC (see EXT2 in 10.5.2). 



Identifier: '6F4B' 


Structure: 


linear fixed 


Optional 


Record length: 13 byte 


s 


Update activity 


: low 


Access Conditions: 
READ 
UPDATE 
INVALIDATE 
REHABILITATE 


CHV1 
CHV2 
ADM 
ADM 






Bytes 


Description 


M/0 


Length 


1 


Record type 


M 


1 byte 


2to12 


Extension data 


M 


1 1 bytes 


13 


Identifier 


M 


1 byte 



For contents and coding see subclause 10.5.10 EFg^^jj. 



1 0.5. 1 2 EFext3 (Extensions) 

This EF contains extension data of an SDN (see EXT3 in 10.5.9). 



Identifier: '6F4C' 


Structure: 


linear fixed 


Optional 


Record length: 13 byte 


s 


Update activity 


: low 


Access Conditions: 
READ 
UPDATE 
INVALIDATE 
REHABILITATE 


CHV1 
ADM 
ADM 
ADM 






Bytes 


Description 


M/0 


Length 


1 


Record type 


M 


1 byte 


2 to 12 


Extension data 


M 


1 1 bytes 


13 


Identifier 


M 


1 byte 



For contents and coding see subclause 10.5.10 EFg^Yi- 

10.5.13 EFbdn (Barred Dialling Numbers) 

This EF contains Barred Dialling Numbers (BDN) and/or Supplementary Service Control strings (SSC). In addition it 
contains identifiers of associated network/bearer capabilities and identifiers of extension records. It may also contain an 
associated alpha-tagging. 
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Identifier: '6F4D' Structure: linear fixed 


Optional 


Record length: X+1 5 bytes Update activity: 


low 


Access Conditions: 

READ CHV1 
UPDATE CHV2 
INVALIDATE CHV2 
REHABILITATE CHV2 


Bytes 


Description 


M/0 


Length 


1 toX 


Alpha Identifier 





X bytes 


X+1 


Length of BCD number/SSC contents 


M 


1 byte 


X+2 


TON and NPI 


M 


1 byte 


X+3toX+12 


Dialling Number/SSC String 


M 


1 bytes 


X+1 3 


Capability/Configuration Identifier 


M 


1 byte 


X+1 4 


Extension4 Record Identifier 


M 


1 byte 


X+1 5 


Comparison IVIethod Information 


M 


1 byte 



For contents and coding of all data items, except for the Comparison Method Information, see the respective data items 
of the EF^Qj,^ (subclause 10.5.1), with the exception that extension records are stored in the EFgxT4- 

NOTE: The value of X (the number of bytes in the alpha-identifier) may be different to the length denoted X in 
EFadn- 

Comparison Method Information 

Contents: 

this byte describes the comparison method which is associated with that BDN. Its interpretation is not 
specified but it shall be defined by the operators implementing the BDN feature on their SIMs. 

Coding: 

binary; values from to 255 are allowed. 



1 0.5. 1 4 EFext4 (Extension4) 

This EF contains extension data of an BDN/SSC (see EXT4 in 10.5.13). 



Identifier: '6F4E' 


Structure: 


linear fixed 


Optional 


Record length: 13 byte 


s 


Update activity 


: low 


Access Conditions: 
READ 
UPDATE 
INVALIDATE 
REHABILITATE 


CHV1 
CHV2 
ADM 
ADM 






Bytes 


Description 


M/0 


Length 


1 


Record type 


M 


1 byte 


2 to 12 


Extension data 


M 


11 bytes 


13 


Identifier 


M 


1 byte 



For contents and coding see subclause 10.5.10 EFg^jj . 

1 0.5. 1 5 EFsMSR (Short message status reports) 

This EF contains information in accordance with GSM 03.40 [13] comprising short message status reports which have 
been received by the MS from the network. 

Each record is used to store the status report of a short message in a record of EFsms- The first byte of each record is the 
link between the status report and the corresponding short message in EFsms- 
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Identifier: '6F47' Structure: linear fixed Optional 


Record length: 30 bytes Update activity: low 


Access Conditions: 

READ CHV1 
UPDATE CHV1 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1 


SMS record identifier 


M 


1 


2-30 


SMS status report 


M 


29 bytes 



SMS record identifier 
Contents: 

This data item identifies the corresponding SMS record in EFsms, eg- if this byte is coded '05' then this status 
report corresponds to the short message in record #5 of EFsms- 
Coding: 

'00' - empty record 

'01 ' - 'FF' - record number of the corresponding SMS in EFsms- 

- SMS status report 
Contents: 

This data item contains the SMS-STATUS-REPORT TPDU as specified in GSM 03.40 [13], with identical 

coding and ordering of parameters. 
Coding: 

according to GSM 03.40 [13]. Any bytes in the record following the TPDU shall be filled with 'FF'. 

1 0.6 DFs at the telecom level 

DFs may be present as child directories of DF-telecom- The following has been defined. 

DFgraphics '5F50' 

1 0.6.1 Contents of files at the telecom graphics level 

The EFs in the Dedicated File DFgraphics contain graphical information. 

10.6.1.1 EFiMG (Image) 

Each record of this EF identifies instances of one particular graphical image, which graphical image is identified by this 
EF's record number. 

Image instances may differ as to their size, having different resolutions, and the way they are coded, using one of several 
image coding schemes. 

As an example, image k may represent a company logo, of which there are i instances on SIM, of various resolutions 
and perhaps encoded in several image coding schemes. Then, the i instances of the company's logo are described in 
record k of this EF. 
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Identifier: '4F20' Structure: linear fixed Optional 


Record length: 9n+2 bytes Update activity: low 


Access Conditions: 

READ CHV1 
UPDATE ADM 
INVALIDATE ADM 
REHABILITATE ADM 


Bytes 


Description 


M/0 


Length 


1 


Number of Actual Image Instances 


M 


1 byte 


2 to 10 


Descriptor of Image Instance 1 


M 


9 bytes 


11 to 19 


Descriptor of Image Instance 2 





9 bytes 










9(n-1) + 2to 
9n + 1 


Descriptor of Image Instance n 





9 bytes 


9n + 2 


RFU 





1 byte 



Number of Actual Image Instances 

Contents: this byte gives the number of actual image instances described in the following data items (i.e. unused 

descriptors are not counted). 
Coding: binary 

Image Instance Descriptor 

Contents: a description of an image instance 

Coding: see below 

Byte 1 : Image Instance Width 
Contents: 

this byte specifies the image instance width, expressed in raster image points. 
Coding: 

binary. 

Byte 2: Image Instance Height 
Contents: 

this byte specifies the image instance height, expressed in raster image points. 
Coding: 

binary. 

Byte 3: Image Coding Scheme 
Contents: 

this byte identifies the image coding scheme that has been used in encoding the image instance. 
Coding: 

'11'- basic image coding scheme as defined in annex G; 

'21' - colour image coding scheme as defined in annex G; 

other values are reserved for future use. 

Bytes 4 and 5: Image Instance File Identifier 
Contents: 

these bytes identify an EF which is the image instance data file (see subclause 10.6.1.2), holding the 

actual image data for this particular instance. 
Coding: 

byte 4: high byte of Image Instance File Identifier; 

byte 5: low byte of Image Instance File Identifier. 

Bytes 6 and 7: Offset into Image Instance File 
Contents: 

these bytes specify an offset into the transparent Image Instance File identified in bytes 4 and 5. 
Coding: 

byte 6: high byte of offset into Image Instance File; 

byte 7: low byte of offset into Image Instance File 
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Note: 



Bytes 8 and 9: Length of Image Instance Data 
Contents: 

these bytes yield the length of the image instance data, starting at the offset identified in bytes 6 and 7. 
Coding: 

byte 8: high byte of Image Instance Data length; 

byte 9: low byte of Image Instance Data length. 

transparent image instance data longer than 256 bytes may be read using successive READ BINARY 
commands. 



1 0.6.1 .2 Image Instance Data Files 

Residing under DFgraphics, there may be several image instance data files. These EFs containing image instance data 
shall have the following attributes: 



Identifier: '4FXX' 




Structure 


transparent 


Optional 


Record length: 


Y bytes 




Update activity: low 


Access Conditions: 
READ 
UPDATE 
INVALIDATE 
REHABILITATE 




CHV1 
ADM 
ADM 
ADM 






Bytes 


Description 


M/0 


Length 


1 toY 


Image Instance Data 


M 


Y bytes 



Contents and coding: 

Image instance data are accessed using the image instance descriptors provided by EFjmg (see subclause 
10.6.1.1). 

The identifier '4FXX' shall be different from one image instance data file to the other. For the range of 'XX', see 
subclause 6.6. The length Y may be different from one image instance data file to the other. 

10.7 Files of GSM 

This subclause contains a figure depicting the file structure of the SIM. DF^^jy] shall be selected using the identifier 
'7F20'. If selection by this means fails, then DCS 1800 MEs shall, and optionally GSM MEs may then select DEg^jy, 
with'7F21'. 

NOTE 1 : The selection of the GSM application using the identifier '7F2 1 ', if selection by means of the identifier 
'7F20' fails, is to ensure backwards compatibility with those Phase 1 SIMs which only support the 
DCS 1800 application using the Phase 1 directory DFj-,(-;§2gQQ coded '7F2r. 

NOTE 2: To ensure backwards compatibility with those Phase 1 DCS 1800 MEs which have no means to select DpQgjyj 
two options have been specified. These options are given in GSM 09.91 [17]. 
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DFgsm 
'7F20' 



DFtelecom 
'7F10' 



DFiRiDIUM 

'5F30' 



DFpcsi900 
'5F40 ' 



EFlp 
6F05' 



EFssT 
'6F38' 



EFspN 
' 6F46' 



EFad 
' 6FAD ' 



EFeMLPP 

' 6FB5' 



MF 
'3F00' 



DFis-41 
'7F22 ' 



DFfp-cts 
'7F23' 



see GSM 11.19 



EFadn 

' 6F3A' 



EFpDN 

' 6F3B' 



EFsMS 
'6F3C' 



EFsMSP 
' 6F42 ' 



EFsMss 
' 6F43' 



EFlnd 
I 6F44' 



EFexti 
' 6F4A' 



EFexT2 

' 6F4B' 



EFexT3 

' 6F4C' 



DFgraphics 
'5F50' 



EFiMG 

'4F20' 



DFglobst 
'5F31' 



DFico 
'5F32 ' 



DFacgs 
'5F33' 



DFcTS 
'5F50' 



DFsoLSA 

'5F70' 



see GSM 11.19 



EFsAl 

'4F30' 



EFiMsi 
' 6F07 ' 



EFkc 
' 6F20' 



EFpLMNsel 

' 6F30' 



EFacm 
'6F39' 



EFgidi 
' 5F3E' 



EFgid2 

' 6F3F' 



EFcBMlD 

' 6F48' 



EFbcch 
' 6F74 ' 



EFacc 
' 6F78 ' 



EFpHASE 

' 6FAE ' 



EFvGcs 
' 6FB1' 



EFvGcss 
' 6FB2' 



EFAAeM 

' 6FB6' 



EFecc 
' 6FB7 ' 



EFcBMlR 

'6F50' 



EFicciD 
'2FE2 ' 



EFccp 
' 6F3D' 



EFsMSR 

' 6F47 ' 



EFbdn 
' 6F4D' 



EFsLL 

'4F31' 



EFhplmn 
'5F31' 



EFpucT 
' 6F41' 



EFppLMN 

' 6F7B' 



EFvBS 
' 6FB3' 



EFnia 
'6F51' 



EFelp 
'2F05' 



EFmsisdn 
' 6F40' 



EFsDN 

1 6F49' 



EFexti 
' 6F4E' 



EFACMmax 

' 6F37' 



EFcBMl 

'6F45' 



EFloci 
' 6F7E' 



EFvBss 
' 6FB4' 



EFkcGPRS 

' 6F52' 



EFlocigprs 
'6F53' 



EFsuME 

' 6F54 ' 



Figure 8: File identifiers and directory structures of GSM 
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1 1 Application protocol 



When involved in GSM administrative management operations, the SIM interfaces with appropriate terminal equipment. 
These operations are outside the scope of the present document. 

When involved in GSM network operations the SIM interfaces with an ME with which messages are exchanged. A 
message can be a command or a response. 

A GSM command/response pair is a sequence consisting of a command and the associated response. 

A GSM procedure consists of one or more GSM command/response pairs which are used to perform all or 
part of an application-oriented task. A procedure shall be considered as a whole, that is to say that the 
corresponding task is achieved if and only if the procedure is completed. The ME shall ensure that, when 
operated according to the manufacturer's manual, any unspecified interruption of the sequence of 
command/response pairs which realize the procedure, leads to the abortion of the procedure itself. 

A GSM session of the SIM in the GSM application is the interval of time starting at the completion of the 
SIM initialization procedure and ending either with the start of the GSM session termination procedure, or at 
the first instant the link between the SIM and the ME is interrupted. 

During the GSM network operation phase, the ME plays the role of the master and the SIM plays the role of the slave. 

Some procedures at the SIM/ME interface require MMI interactions. The descriptions hereafter do not intend to infer 
any specific implementation of the corresponding MMI. When MMI interaction is required, it is marked "MMI" in the 
list given below. 

Some procedures are not clearly user dependent. They are directly caused by the interaction of the MS and the network. 
Such procedures are marked "NET" in the list given below. 

Some procedures are automatically initiated by the ME. They are marked "ME" in the list given below. 

The list of procedures at the SIM/ME interface in GSM network operation is as follows: 

General Procedures: 

Reading an EF ME 

Updating an EF ME 

Increasing an EF ME 

SIM management procedures: 

SIM initiahzation ME 

GSM session termination ME 

Emergency call codes request ME 

Extended language preference request ME 

Language preference request ME 

Administrative information request ME 

SIM service table request ME 

SIM phase request ME 

CHV related procedures: 

CHV verification MMI 

CHV value substitution MMI 

CHV disabling MMI 

CHV enabling MMI 

CHV unblocking MMI 
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GSM security related procedures: 



GSM algorithms computation 

IMSI request 

Access control information request 

HPLMN search period request 

Location Information 

Cipher key 

BCCH information 

Forbidden PLMN information 

LSA information 



NET 
NET 
NET 
NET 
NET 
NET 
NET 
NET 
NET 



Subscription related procedures: 



DialHng Numbers (ADN, FDN, MSISDN, LND, SDN, BDN) 

Short messages (SMS) 

Advice of Charge (AoC) 

Capability Configuration Parameters (CCP) 

PLMN Selector 

Cell Broadcast Message Identifier (CBMI) 

Group Identifier Level 1 (GIDl) 

Group Identifier Level 2 (GID2) 

Service Provider Name (SPN) 

Voice Group Call Service (VGCS) 

Voice Broadcast Service (VBS) 

Enhanced Multi Level Pre-emption and Priority (eMLPP) 

Depersonalisation Control Keys 

Short message status reports (SMSR) 

Network's indication of alerting 



MMI/ME 

MMI 

MMI 

MMI 

MMI 

MMI 

MMI/ME 

MMI/ME 

ME 

MMI/ME 

MMI/ME 

MMI/ME 

ME 

MMI 

ME 



SIM Application Toolkit related procedures: 

Data Download via SMS-CB (CBMID) 

Data Download via SMS-PP 

Menu selection 

Call Control 

Proactive SIM 

Mobile Originated Short Message control by SIM 

Image Request 



NET 

NET 

MMI 

MMI/ME/NET 

MMI/ME/NET 

MMI/ME/NET 

MMI/ME 



The procedures listed in subclause 11 .2 are basically required for execution of the procedures in subclauses 11.3, 1 1 .4 
and 1 1.5. The procedures listed in subclauses 11. 3 and 1 1.4 are mandatory (see GSM 02.17 [6]). The procedures listed 
in 1 1 .5 are only executable if the associated services, which are optional, are provided in the SIM. However, if the 
procedures are implemented, it shall be in accordance with subclause 1 1.5. 

If a procedure is related to a specific service indicated in the SIM Service Table, it shall only be executed if the 
corresponding bits denote this service as "allocated and activated" (see subclause 10.3.7). In all other cases this 
procedure shall not start. 

11.1 General procedures 
11.1.1 Reading an EF 

The ME selects the EF and sends a READ command. This contains the location of the data to be read. If the access 
condition for READ is fulfilled, the SIM sends the requested data contained in the EF to the ME. If the access condition 
is not fulfilled, no data will be sent and an error code will be returned. 
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11.1.2 Updating an EF 



The ME selects the EF and sends an UPDATE command. This contains the location of the data to be updated and the 
new data to be stored. If the access condition for UPDATE is fulfilled, the SIM updates the selected EF by replacing the 
existing data in the EF with that contained in the command. If the access condition is not fulfilled, the data existing in 
the EF will be unchanged, the new data will not be stored, and an error code will be returned. 



11.1.3 Increasing an EF 



The ME selects the EF and sends an INCREASE command. This contains the value which has to be added to the 
contents of the last updated/increased record. If the access condition for INCREASE is fulfilled, the SIM increases the 
existing value of the EF by the data contained in the command, and stores the result. If the access condition is not 
fulfilled, the data existing in the EF will be unchanged and an error code will be returned. 

NOTE: The identification of the data within an EF to be acted upon by the above procedures is specified within 
the command. For the procedures in subclauses 11.1.1 and 11.1.2 this data may have been previously 
identified using a SEEK command, e.g. searching for an alphanumeric pattern. 



1 1 .2 SIM management procedures 



Phase 2 MEs shall support all SIMs which comply with the mandatory requirements of Phase 1, even if these SIMs do 
not comply with all the mandatory requirements of Phase 2. Furthermore, Phase 2 MEs shall take care of potential 
incompatibilities with Phase 1 SIMs which could arise through use of inappropriate commands or misinterpretation of 
response data. Particular note should be taken of making a false interpretation of RFU bytes in a Phase 1 SIM having 
contradictory meaning in Phase 2; e.g. indication of EF invalidation state. 

11.2.1 SIM initialization 

After SIM activation (see subclause 4.3.2), the ME selects the Dedicated File DFQgjyj and optionally attempts to select 
^^ECC- ^f Ef^ECC i^ available, the ME requests the emergency call codes. 

The ME requests the Extended Language Preference. The ME only requests the Language Preference (EFlp) if at least 
one of the following conditions holds: 

EFelp is not available; 

EFelp does not contain an entry corresponding to a language specified in ISO 639 [30]; 

the ME does not support any of the languages in EFel?. 

If both EFs are not available or none of the languages in the EFs is supported then the ME selects a default language. It 
then runs the CHVl verification procedure. 

If the CHVl verification procedure is performed successfully, the ME then runs the SIM Phase request procedure. 

For a SIM requiring PROFILE DOWNLOAD, then the ME shall perform the PROFILE DOWNLOAD procedure in 
accordance with GSM 1 1.14 [27]. When BDN is enabled on a SIM, the PROFILE DOWNLOAD procedure is used to 
indicate to the SIM whether the ME supports the "Call Control by SIM" facility. If so, then the SIM is able to allow the 
REHABILITATE command to rehabilitate EFjjyj^j and EFloci- 

If the ME detects a SIM of Phase 1, it shall omit the following procedures relating to FDN and continue with the 
Administrative Information request. The ME may omit procedures not defined in Phase 1 such as HPLMN Search 
Period request. 

For a SIM of Phase 2 or greater, GSM operation shall only start if one of the two following conditions is fulfilled: 

if EFj]y[5j and EFlq^^j are not invalidated, the GSM operation shall start immediately; 

if EFj]y[5j and EFlq^^j are invalidated, the ME rehabilitates these two EFs. 

MEs without FDN capability but with Call control by SIM facility shall not rehabilitate EFjjyjgj and/or EFlqci if 
FDN is enabled in the SIM and therefore have no access to these EFs. GSM operation will therefore be 
prohibited; 
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MEs without FDN capability and without Call control by SIM facility shall not rehabilitate EFjjyjgj and/or EFjjy^^ 
and therefore have no access to these EFs. GSM operation will therefore be prohibited. 

It is these mechanisms which are used for control of services n°3 and n°3 1 by the use of SIMs for these services 
which always invalidate these two EFs at least before the next command following selection of either EF. 

NOTE: When FDN and BDN are both enabled, and if the ME supports FDN but does not support the Call control 
by SIM facility, the rehabilitation of EFjjyjgj and EF^q^j will not be successful because of a restriction 
mechanism of the REHABILITATE command linked to the BDN feature. 

When EFjj^gj and EF^q^j are successfully rehabilitated, if the FDN capability procedure indicates that: 

i) FDN is allocated and activated in the SIM; and FDN is set "enabled", i.e. ADN "invalidated" or not activated; 
and the ME supports FDN; 

or ii) FDN is allocated and activated in the SIM; and FDN is set "disabled", i.e. ADN "not invalidated"; 

or iii) FDN is not allocated or not activated; 

then GSM operation shall start. 

In all other cases GSM operation shall not start. 

Afterwards, the ME runs the following procedures: 

Administrative Information request; 
SIM Service Table request; 

- IMSI request; 
Access Control request; 

- HPLMN Search Period request; 
PLMN selector request; 
Location Information request; 
Cipher Key request; 

BCCH information request; 
Forbidden PLMN request; 
LSA information request; 

- CBMID request; 
Depersonalisation Control Keys request; 
Network's indication of alerting request. 

If the SIM service table indicates that the proactive SIM service is active, then from this point onwards, the ME, if it 
supports the proactive SIM service, shall send STATUS commands at least every 30s during idle mode as well as during 
calls, in order to enable the proactive SIM to respond with a command. The SIM may send proactive commands (see 
GSM n.l4 [27]), including a command to change the interval between STATUS commands from the ME, when in idle 
mode. In-call requirements for STATUS for SIM Presence Detection are unchanged by this command. 

After the SIM initialization has been completed successfully, the MS is ready for a GSM session. 

1 1 .2.2 GSM session termination 

NOTE 1: This procedure is not to be confused with the deactivation procedure in subclause 4.3.2. 

The GSM session is terminated by the ME as follows: 

The ME runs all the procedures which are necessary to transfer the following subscriber related information to the SIM: 
Location Information update; 
Cipher Key update; 
BCCH information update; 
Advice of Charge increase; 

- Forbidden PLMN update. 

As soon as the SIM indicates that these procedures are completed, the ME/SIM link may be deactivated. 
Finally, the ME deletes all these subscriber related information elements from its memory. 
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NOTE 2: If the ME has already updated any of the subscriber related information during the GSM Session, and the 
value has not changed until GSM session termination, the ME may omit the respective update procedure. 

1 1 .2.3 Emergency Call Codes 

Request: The ME performs the reading procedure with EFg,-;^. 

Update: The ME performs the updating procedure with EFgj;^,-;. 

NOTE: The update procedure is only applicable when access conditions of ADM for update is set to ALW, CHVl 
or CHV2. 

1 1 .2.4 Language preference 

Request: The ME performs the reading procedure with EF^p. 

Update: The ME performs the updating procedure with EFj^p. 

1 1 .2.5 Administrative information request; 

The ME performs the reading procedure with EF^sjj. 

1 1 .2.6 SIM service table request 

The ME performs the reading procedure with EFg^j. 

1 1 .2.7 SIM phase request 

The ME performs the reading procedure with EFpj^^^g. 

1 1 .2.8 SIM Presence Detection and Proactive Polling 

As an additional mechanism, to ensure that the SIM has not been removed during a card session, the ME sends, at 
frequent intervals, a STATUS command during each call. A STATUS command shall be issued within all 30 second 
periods of inactivity on the SIM-ME interface during a call. Inactivity in this case is defined as starting at the end of the 
last communication or the last issued STATUS command. If no response data is received to this STATUS command, 
then the call shall be terminated as soon as possible but at least within 5 seconds after the STATUS command has been 
sent. If the DF indicated in response to a STATUS command is not the same as that which was indicated in the previous 
response, or accessed by the previous command, then the call shall be terminated as soon as possible but at least within 
5 seconds after the response data has been received. This procedure shall be used in addition to a mechanical or other 
device used to detect the removal of a SIM. 

If the ME supports the proactive SIM service, and the SIM has this service activated in its Service Table, then during 
idle mode the ME shall send STATUS commands to the SIM at intervals no longer than the interval negotiated with the 

SIM (see GSM 11.14 [27]). 

1 1 .2.9 Extended Language preference 

Request: The ME performs the reading procedure with EF^|_p. 

Update: The ME performs the updating procedure with EF^Lp. 

1 1 .3 CHV related procedures 

A successful completion of one of the following procedures grants the access right of the corresponding CHV for the 
GSM session. This right is valid for all files within the GSM application protected by this CHV. 

After a third consecutive presentation of a wrong CHV to the SIM, not necessarily in the same GSM session, the CHV 
status becomes "blocked" and if the CHV is "enabled", the access right previously granted by this CHV is lost 
immediately. 
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An access right is not granted if any of the following procedures are unsuccessfully completed or aborted. 

11.3.1.1 CHV verification 

The ME checks the CHV status. 

In the case of CHV 1 the following procedure applies: 

If the CHVl status is "blocked" and CHVl is "enabled", the procedure ends and is finished unsuccessfully. 

If the CHVl status is "blocked" but CHVl is "disabled", the procedure ends and is finished successfully. The ME 
shall, however, accept SIMs which do not grant access rights when CHVl is "blocked" and "disabled". In that 
case ME shall consider those SIMs as "blocked". 

If the CHVl status is not "blocked" and CHVl is "disabled", the procedure is finished successfully. 

If the CHVl status is not "blocked" and CHVl is "enabled", the ME uses the VERIFY CHV function. If the 
CHVl presented by the ME is equal to the corresponding CHVl stored in the SIM, the procedure is finished 
successfully. If the CHVl presented by the ME is not equal to the corresponding CHVl stored in the SIM, the 
procedure ends and is finished unsuccessfully. 

In the case of CHV2 the following procedure applies: 

If the CHV2 status is "blocked", the procedure ends and is finished unsuccessfully. 

If the CHV2 status is not "blocked", the ME uses the VERIFY CHV function. If the CHV2 presented by the ME 
is equal to the corresponding CHV2 stored in the SIM, the procedure is finished successfully. If the CHV2 
presented by the ME is not equal to the corresponding CHV2 stored in the SIM, the procedure ends and is 
finished unsuccessfully. 

11.3.1.2 Not used 

1 1 .3.2 CHV value substitution 

The ME checks the CHV status. If the CHV status is "blocked" or "disabled", the procedure ends and is finished 
unsuccessfully. 

If the CHV status is not "blocked" and the enabled/disabled indicator is set "enabled", the ME uses the CHANGE CHV 
function. If the old CHV presented by the ME is equal to the corresponding CHV stored in the SIM, the new CHV 
presented by the ME is stored in the SIM and the procedure is finished successfully. 

If the old CHV and the CHV in memory are not identical, the procedure ends and is finished unsuccessfully. 

11.3.3 CHV disabling 

Requirement: Service n°l "allocated and activated". 

The ME checks the CHVl status. If the CHVl status is "blocked", the procedure ends and is finished unsuccessfully. 

If the CHVl status is not "blocked", the ME reads the CHVl enabled/disabled indicator. If this is set "disabled", the 
procedure ends and is finished unsuccessfully. 

If the CHVl status is not "blocked" and the enabled/disabled indicator is set "enabled", the ME uses the DISABLE 
CHV function. If the CHVl presented by the ME is equal to the CHVl stored in the SIM, the status of CHVl is set 
"disabled" and the procedure is finished successfully. If the CHVl presented by the ME is not equal to the CHVl stored 
in the SIM, the procedure ends and is finished unsuccessfully. 

11.3.4 CHV enabling 

The ME checks the CHVl status. If the CHVl status is "blocked", the procedure ends and is finished unsuccessfully. 
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If the CHVl status is not "blocked", the ME reads the CHVl enabled/disabled indicator. If this is set "enabled", the 
procedure ends and is finished unsuccessfully. 

If the CHVl status is not "blocked" and the enabled/disabled indicator is set "disabled", the ME uses the ENABLE 
CHV function. If the CHVl presented by the ME is equal to the CHVl stored in the SIM, the status of CHVl is set 
"enabled" and the procedure is finished successfully. If the CHV presented by the ME is not equal to the CHVl stored 
in the SIM, the procedure ends and is finished unsuccessfully. 

11.3.5 CHV unblocking 

The execution of the CHV unblocking procedure is independent of the corresponding CHV status, i.e. being blocked or 
not. 

The ME checks the UNBLOCK CHV status. If the UNBLOCK CHV status is "blocked", the procedure ends and is 
finished unsuccessfully. 

If the UNBLOCK CHV status is not "blocked", the ME uses the UNBLOCK CHV function. If the UNBLOCK CHV 
presented by the ME is equal to the corresponding UNBLOCK CHV stored in the SIM, the relevant CHV status 
becomes "unblocked" and the procedure is finished successfully. If the UNBLOCK CHV presented by the ME is not 
equal to the corresponding UNBLOCK CHV stored in the SIM, the procedure ends and is finished unsuccessfully. 

1 1 .4 GSM security related procedures 

1 1 .4.1 GSM algorithms computation 

The ME selects DFgsjy, and uses the RUN GSM ALGORITHM function (see 8.16). The response SRES-Kc is sent to 
the ME when requested by a subsequent GET RESPONSE command. 

11.4.2 IMSI request 

The ME performs the reading procedure with EFjjyjgj. 

1 1 .4.3 Access control request 

The ME performs the reading procedure with EF^(-.(-;. 

1 1 .4.4 HPLMN search period request 

The ME performs the reading procedure with EFj^p^jy^f^. 

1 1 .4.5 Location information 

Request: The ME performs the reading procedure with EFloci- 

Update: The ME performs the updating procedure with EFlq^^j. 

11.4.6 Cipher key 

Request: The ME performs the reading procedure with EFj^^,. 

Update: The ME performs the updating procedure with EFj^,,. 

11.4.7 BCCH information 

Request: The ME performs the reading procedure with EF^qq^^. 

Update: The ME performs the updating procedure with EFg(-.(-;jj. 
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1 1 .4.8 Forbidden PLMN 

Request: The ME performs the reading procedure with EFpLjyjjs^. 

Update: The ME performs the updating procedure with EFpLf^j^. 

1 1 .4.9 LSA information 

Request: The ME performs the reading procedure with EF§^j, EF^^l ^i^d it^ associated LSA Descriptor 

files. 
Update: The ME performs the updating procedure with EFgL^. 

1 1 .5 Subscription related procedures 
11.5.1 Dialling numbers 

The following procedures may not only be applied to EF^jjf^ and its associated extension files EF(-;Qp and EEgj^-p^ as 
described in the procedures below, but also to EFp^j,^, EFf^gj^pj^, EFlnq, EFg£,j^ and EF§£,f^ and their associated 
extension files. If these files are not allocated and activated, as denoted in the SIM service table, the current procedure 
shall be aborted and the appropriate EFs shall remain unchanged. 

As an example, the following procedures are described as applied to ADN. 

Requirement: Service n°2 "allocated and activated" 

(Service n°3 for FDN, 
Service n°9 for MSISDN, 
Service n°13 for END, 
Service n° 18 for SDN), 
Service n°31 for BDN) 

Update: The ME analyses and assembles the information to be stored as follows (the byte identifiers used 

below correspond to those in the description of the EFs in subclauses 10.5.1, 10.5.4 and 10.5.10): 

i) The ME identifies the Alpha-tagging, Capability/Configuration Identifier and Extension 1 Record Identifier. 

ii) The dialling number/SSC string shall be analysed and allocated to the bytes of the EF as follows: 

if a "+" is found, the TON identifier is set to "International"; 

if 20 or less "digits" remain, they shall form the dialling number/SSC string; 

if more than 20 "digits" remain, the procedure shall be as follows: 

Requirement: 

Service n°10 "allocated and activated" 

(Service n°10 applies also for MSISDN and END; 

Service n° 11 for FDN; 

Service n°19 for SDN; 

Service n°32 for BDN.) 

The ME seeks for a free record in EEgj^^^. If an Extensionl record is not marked as "free", the ME runs the 
Purge procedure. If an Extensionl record is still unavailable, the procedure is aborted. 

The first 20 "digits" are stored in the dialling number/SSC string. The value of the length of BCD 
number/SSC contents is set to the maximum value, which is 1 1. The Extensionl record identifier is coded 
with the associated record number in the EFg^jj. The remaining digits are stored in the selected Extensionl 
record where the type of the record is set to "additional data". The first byte of the Extensionl record is set 
with the number of bytes of the remaining additional data. The number of bytes containing digit information 
is the sum of the length of BCD number/SSC contents of EF^^j^ and byte 2 of all associated chained 
Extensionl records containing additional data (see subclauses 10.5.1 and 10.5.10). 

iii) If a called party subaddress is associated to the ADN/SSC the procedure shall proceed as follows: 
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Requirement: 

Service n°10 "allocated and activated" 

(Service n°10 applies also for MSISDN and LND; 

Service n° 11 forFDN; 

Service n°19 for SDN; 

Service n°32 for BDN.) 

If the length of the called party subaddress is less than or equal to 11 bytes (see GSM 04.08 [15] for coding): 

The ME seeks for a free record in EFgj^-p^. If an Extensionl record is not marked as "free", the ME runs the 
Purge procedure. If an Extensionl record is still unavailable, the procedure is aborted. 

The ME stores the called party subaddress in the Extensionl record, and sets the Extensionl record type to 
"called party subaddress". 

If the length of the called party subaddress is greater than 11 bytes (see GSM 04.08 [15] for coding): 

The ME seeks for two free records in EFgj^-pi- If ^lo such two records are found, the ME runs the Purge 
procedure. If two Extensionl records are still unavailable, the procedure is aborted. 

The ME stores the called party subaddress in the two Extensionl records. The identifier field in the 
Extensionl record containing the first part of the subaddress data is coded with the associated EFg^^i record 
number containing the second part of the subaddress data. Both Extensionl record types are set to "called 
party subaddress". 

Once i), ii), and iii) have been considered the ME performs the updating procedure with EF^y-,f^. If the SIM has no 
available empty space to store the received ADN/SSC, or if the procedure has been aborted, the ME advises the user. 

NOTE 1: For reasons of memory efficiency the ME is allowed to analyse all Extensionl records to recognize if the 
additional or subaddress data to be stored is already existing in EFg^xi- ^^ this case the ME may use the 
existing chain or the last part of the existing chain from more than one ADN (LND, MSISDN). The ME is 
only allowed to store extension data in unused records. If existing records are used for multiple access, the 
ME shall not change any data in those records to prevent corruption of existing chains. 

Erasure: The ME sends the identification of the information to be erased. The content of the identified 

record in EF^j-,j^ is marked as "free". 

Request: The ME sends the identification of the information to be read. The ME shall analyse the data of 

Ef'ADN (subclause 10.5.1) to ascertain, whether additional data is associated in EFg^jj or EF(;^(-^p. 
If necessary, then the ME performs the reading procedure on these EFs to assemble the complete 
ADN/SSC. 

Purge: The ME shall access each EF which references EFgj^-p^ (^^ext2^ ^'-'^ storage and shall identify 

records in these files using extension data (additional data or called party subaddress). Note that 
existing chains have to be followed to the end. All referred Extensionl (Extension2) records are 
noted by the ME. All Extensionl (Extension2) records not noted are then marked by the ME as 
"free" by setting the whole record to 'FF'. 

NOTE 2: Dependent upon the implementation of the ME, and in particular the possibility of erasure of ADN/SSC 
records by Phase 1 MEs, which have no knowledge of the EFg^xi' i^ is possible for Extensionl records to 
be marked as "used space" (not equal to 'FF'), although in fact they are no longer associated with an 
ADN/SSC record. 

The following three procedures are only applicable to service n°3 (FDN). 

FDN capability request. The ME has to check the state of service n°3, i.e. if FDN is "enabled" or "disabled". In case of 
enabled FDN, the ME has to switch to a restrictive terminal mode (see GSM 02.07). To ascertain the state of FDN, the 
ME checks in EF^^j whether or not ADN is activated. If ADN is not activated, service n°3 is enabled. If ADN is 
activated, the ME checks the response data of EF^^j,^. If EF^^j,^ is invalidated, service n°3 is enabled. In all other cases 
service n°3 is disabled. 

FDN disabling. The FDN disabling procedure requires that CHV2 verification procedure has been performed 
successfully and that ADN is activated. If not, FDN disabling procedure will not be executed successfully. To disable 
FDN capability, the ME rehabilitates EF^^j^. The invalidate/rehabilitate flag of EF^^j,^, which is implicitly set by the 
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REHABILITATE command, is at the same time the indicator for the state of the service n°3. If ADN is not activated, 
disabling of FDN is not possible and thus service n°3 is always enabled (see FDN capability request). 

NOTE 3: If FDN is disabled (by rehabilitating EF^pj^) using an administrative terminal then the FDN disabling 
procedure of this administrative terminal need also to rehabilitate EFjjyjgj and EFlqqj to ensure normal 
operation of the SIM in a phase 1 ME or a phase 2 ME which does not support FDN. 

FDN enabling. The FDN enabling procedure requires that CHV2 verification procedure has been performed 
successfully. If not, FDN enabling procedure will not be executed successfully. To enable FDN capability, the ME 
invalidates EF^^j,^. The invalidate/rehabilitate flag of EF^y-,j^, which is implicitly cleared by the INVALIDATE 
command, is at the same time the indicator for the state of the service n°3 (see FDN capability request). If ADN is not 
activated, service n°3 is always enabled. 

Invalidated ADNs may optionally still be readable and updatable depending on the file status (see clause 9.3) 

The following three procedures are only applicable to service n°31 (BDN). 

BDN capability request. The ME has to check the state of service n°31, i.e. if BDN is "enabled" or "disabled". BDN 
service is "enabled" only if service n°31 is allocated and activated, and EFg^f^ is not invalidated. In all other cases, the 
BDN service is "disabled". 

BDN disabling. The BDN disabling procedure requires that CHV2 verification procedure has been performed 
successfully. If not, BDN disabling procedure will not be executed successfully. To disable BDN capability, the ME 
invalidates EFg^j.^. The invalidate/rehabilitate flag of EFg£,j^, which is implicitly cleared by the INVALIDATE 
command, is at the same time the indicator for the state of the service n°31 (see BDN capability request). 

BDN enabling. The BDN enabling procedure requires that CHV2 verification procedure has been performed 
successfully. If not, BDN enabling procedure will not be executed successfully. To enable BDN capability, the ME 
rehabilitates EFgpj^. The invalidate/rehabilitate flag of EFgj-,|vj, which is implicitly set by the REHABILITATE 
command, is at the same time the indicator for the state of the service n°31 (see BDN capability request). 

Invalidated BDNs (when BDN capability is disabled) may optionally still be readable and updatable depending on the 
file status (see clause 9.3). 

1 1 .5.2 Short messages 

Requirement: Service n°4 "allocated and activated". 



Request: 



Update: 



Erasure: 



The SIM seeks for the identified short message. If this message is found, the ME performs the 
reading procedure with EFgjyjg. 

If service n°35 is "allocated and activated" and the status of the SMS is 'ID' (status report 
requested, received and stored in EFsmsr)^ the ME performs the reading procedure with the 
corresponding record in EFsmsr- If the ME does not find a corresponding record in EFsmsr^ then 
the ME shall update the status of the SMS with '19' (status report requested, received but not stored 
in EFsmsr)- 

If the short message is not found within the SIM memory, the SIM indicates that to the ME. 

The ME looks for the next available area to store the short message. If such an area is available, it 
performs the updating procedure with EFgjy,^. 

If there is no available empty space in the SIM to store the received short message, a specific MMI 
will have to take place in order not to loose the message. 

The ME will select in the SIM the message area to be erased. Depending on the MMI, the message 
may be read before the area is marked as "free". After performing the updating procedure with 
E^SMS' '■hs memory allocated to this short message in the SIM is made available for a new 
incoming message. The memory of the SIM may still contain the old message until a new message 
is stored in this area. 
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If service n°35 is "allocated and activated" and the status of the SMS is 'ID' (status report 
requested, received and stored in EFsmsr), the ME performs the erasure procedure for EFsmsr with 
the corresponding record in EFsmsr- 

1 1 .5.3 Advice of Charge (AoC) 

Requirement: Service n°5 "allocated and activated". 

Accumulated Call Meter. 

Request: The ME performs the reading procedure with EF^,-;;^. The SIM returns the last updated value of 

the ACM. 
Initialization: The ME performs the updating procedure with EF^f^jyj using the new initial value. 

Increasing: The ME performs the increasing procedure with EF^j-^jyj sending the value which has to be added. 

Accumulated Call Meter Maximum Value. 

Request: The ME performs the reading procedure with EF^(-;[^j^jj^. 

Initialization: The ME performs the updating procedure with EF^^jyjjjjjj^ using the new initial maximum value. 

Price per Unit and Currency Table (PUCT). 

Request: The ME performs the reading procedure with EFpu^^-p- 

Update: The ME performs the updating procedure with EFpucj- 

1 1 .5.4 Capability configuration parameters 

Requirement: Service n°6 "allocated and activated". 

Request: The ME performs the reading procedure with EFQ(-;p. 

Update: The ME performs the updating procedure with EF(-^(;^p. 

Erasure: The ME sends the identification of the requested information to be erased. The content of the 

identified record in EF(-;(-.p is marked as "free". 

1 1 .5.5 PLMN selector 

Requirement: Service n°7 "allocated and activated". 

Request: The ME performs the reading procedure with EFpL[^[,^ggj. 

Update: The ME performs the updating procedure with EFpLMNsei- 

1 1 .5.6 Cell broadcast message identifier 

Requirement: Service n°14 "allocated and activated". 

Request: The ME performs the reading procedure with EF(;;g[^j. 

Update: The ME performs the updating procedure with EF(-^g]y[j. 

1 1 .5.7 Group identifier level 1 

Requirement: Service n°15 "allocated and activated". 

Request: The ME performs the reading procedure with EFqjj-,j. 

1 1 .5.8 Group identifier level 2 

Requirement: Service n°16 "allocated and activated". 

Request: The ME performs the reading procedure with EFqjj-,2- 

1 1 .5.9 Service Provider Name 

Requirement: Service n°17 "allocated and activated". 

Request: The ME performs the reading procedure with EFgpj^. 
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11.5.10 Voice Group Call Services 

Requirement: Service n°18 "allocated and activated". 

Voice Group Call Service 

Request: The ME performs the reading procedure with EFVGCS. 

Voice Group Call Service Status 

Request: The ME performs the reading procedure with EFVGCSS. 

Update: The ME performs the updating procedure with EFVGCSS. 

1 1 .5.1 1 Voice Broadcast Services 

Requirement: Service n°19 "allocated and activated". 

Voice Broadcast Service 

Request: The ME performs the reading procedure with EFygg. 

Voice Broadcast Service Status 

Request: The ME performs the reading procedure with EFyg^g. 

Update: The ME performs the updating procedure with EFyg^g. 

1 1 .5.12 Enhanced Multi Level Pre-emption and Priority Service 

Requirement: Service n°18 "allocated and activated". 

Enhanced Multi Level Pre-emption and Priority 

Request: The ME performs the reading procedure with EEgf^^pp. 

Automatic Answer on eMLPP service 

Request: The ME performs the reading procedure with EF^^^jy;. 

Update: The ME performs the updating procedure with EF^^^jyj. 

1 1 .5.13 Cell Broadcast Message range identifier 

Requirement: Service n°30 "allocated and activated". 

Request: The ME performs the reading procedure with EFf^gjyfjjj. 

Update: The ME performs the updating procedure with EF(-;g]y[jj^. 

11.5.14 Depersonalisation Control Keys 

Requirement: Service n°33 "allocated and activated". 

Request: The ME performs the reading procedure with EFq^-j^. 

1 1 .5.1 5 Short message status report 

Requirement: Service n°35 "allocated and activated". 

Request: If the status of a stored short message indicates that there is a corresponding status report, the ME 

performs the seek function with EFsmsr to identify the record containing the appropriate status 
report. The ME performs the reading procedure with EFgy5pj. 

Update: If a status report is received, the ME first seeks within the SMS record identifiers of EFsmsr for the 

same record number it used for the short message in EFsms- If such a record identifier is found in 
EFsmsr^ it is used for storage. If such a record identifier is not found, then the ME seeks for a free 
entry in EFsmsr for storage. If no free entry is found the ME runs the Purge procedure with EFsmsr- 
If there is still no free entry, the status report is not stored. 
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If the ME found an appropriate record in EFsmsr for storage, it updates the record with the status 
report setting the record identifier in EFsmsr to the appropriate record number of the short message 
in EFsMs- 

The status in EFsms is updated accordingly (see 10.5.3) by performing the update procedure with 

EFsMs- 

Erasure: The ME runs the update procedure with EFsmsr by at least storing '00' in the first byte of the 

record. The ME may optionally update the following bytes with 'FF'. 

Purge: The ME shall read the SMS record identifier (byte 1) of each record of EFsmsr- With each record 

the ME checks the corresponding short messages in EFsms- If the status (byte 1) of the 
corresponding SMS is not equal 'ID' (status report requested, received and stored in EFsmsr)^ the 
ME shall perform the erasure procedure with the appropriate record in EFsmsr- 

11 .5.1 6 Network's indication of alerting 

Requirement: Service n°36 "allocated and activated". 

Request: The ME performs the reading procedure with EFj,^]^. 

1 1 .6 SIM Application Toolkit related procedures 

SIM Application Toolkit is an optional feature. The higher level procedures, and contents and coding of the commands, 
are given in GSM 11.14 [27] . Procedures relating to the transmission of commands and responses across the SIM/ME 
interface are given in this section. A SIM or ME supporting SIM Application Toolkit shall conform to the requirements 
given in this section. 

1 1 .6.1 Initialization procedure 

A SIM supporting SIM Application Toolkit shall indicate this through relevant data in EEpj^^j.^ and EFg^j, as defined in 
the relevant sections above. 

An ME supporting SIM Application Toolkit shall perform initialization as defined in the SIM Initialization section 
above. 



1 1 .6.2 Proactive polling 



An ME supporting proactive SIM (part of SIM Application Toolkit) shall support the polling procedure as defined 
above. 



1 1 .6.3 Support of commands 



A SIM or ME supporting SIM Application Toolkit shall support the commands TERMINAL PROFILE, ENVELOPE, 
FETCH and TERMINAL RESPONSE. 

These commands shall never be used if either the SIM or ME does not support SIM Application Toolkit. Therefore 
standard SIMs and MEs do not need to support these commands. 



1 1 .6.4 Support of response codes 



A SIM or ME supporting SIM Application Toolkit shall support the response status words (SWl SW2) '91 XX', and 
'93 00' and '9E XX'. The SIM shall send '9E XX' only to an ME indicating in TERMINAL PROFILE that it supports the 
handling of these status words. 

These responses shall never be used if either the SIM or ME does not support SIM Application Toolkit. Therefore 
standard SIMs and MEs do not need to support them. 
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1 1 .6.5 Command-response pairs 

Using the terminology where the ME issues a command and the SIM a response, ending in status words SWl SW2, a 
command-response pair is considered as a single transaction. Each transaction is initiated by the ME and terminated by 
the SIM. One transaction must be completed before the next one can be initiated. This protocol applies to SIM 
Application Toolkit in the same way as it does to normal operation. 

1 1 .6.6 Independence of normal GSM and SIM Application Toolkit tasks 

Normal GSM operation (relating to general, CHV related, GSM security related, and subscription related procedures) 
and SIM Application Toolkit operation shall be logically independent, both in the SIM and in the ME. 

Specifically, this means: 

The currently selected EF and current record pointer in the normal GSM task shall remain unchanged, if still 
valid, as seen by the ME, irrespective of any SIM Application Toolkit activity. 

Between successive SIM Application Toolkit related command-response pairs, other normal GSM related 
command-response pairs can occur. The SIM Application Toolkit task status shall remain unchanged by these 
command-response pairs. 

1 1 .6.7 Use of BUSY status response 

If for any reason the SIM Application Toolkit task of the SIM cannot process an ENVELOPE command issued by the 
ME at present (e.g. other SIM Application Toolkit processes are already running, and this additional one would cause an 
overload), the SIM can respond with a status response of '93 00'. The ME may re-issue the command at a later stage. 

The BUSY status response has no impact on normal GSM operation. 



1 1 .6.8 Use of NULL procedure byte 



The NULL procedure byte provides a mechanism for the SIM to obtain more time before supplying the response part of 
a command-response pair, during which time the ME is unable to send further commands to the SIM. 

If a SIM Application Toolkit activity in the SIM runs for too long, this may prevent the ME from sending "normal 
GSM" commands which are time-critical, e.g. RUN GSM ALGORITHM. A MORE TIME command is defined in 
GSM 1 1.14 [27], which ensures that the SIM Application Toolkit task in the SIM gets more processing time, while at 
the same time freeing the SIM/ME interface. This should be used in preference to NULL procedure bytes ('60'). 

1 1 .6.9 Using the TERMINAL PROFILE, ENVELOPE, and TERMINAL 
RESPONSE commands 

These commands are part of the set used by SIM Application Toolkit. The use of the these commands, the occasions 
where they are required, and the command and response parameters associated with the commands, are specified in 
GSM n . 14 [27] . The ME completes the command parameters/data of the relevant command and sends the command to 
the SIM. The transmitted data is processed by the SIM in a specific way depending on the tag value in the command 
parameters. 

A SIM or ME not supporting SIM Application Toolkit does not need to support these commands. 



11.6.10 Using the FETCH command 



This command is used by SIM Application Toolkit. The use of the this command, the occasions where it is required, and 
the command and response parameters associated with the command, are specified in GSM 11. 14 [27]. It is similar in 
function to GET RESPONSE, in that it requests response parameters from the SIM, following a '91 XX' status response. 
The transmitted response data from the SIM is processed by the ME in a specific way depending on the tag value in the 
response parameters. 

A SIM or ME not supporting SIM Application Toolkit does not need to support this command. 
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11.6.11 Data Download via SMS-CB 

Requirement: Service n°25 "allocated and activated". 

The ME shall perform the reading procedure with EF(-.g[y[j£). On receiving a cell broadcast message with an identifier 
which matches an identifier in EFcbmid^ the ME shall pass the CB message to the SIM using the ENVELOPE command. 
If a match is not found and service no. 14 is "allocated and activated", then the message identifier is checked against 
those in EF(-g,^j. 

11.6.12 Data Download via SMS-PP 

Requirement: Service n°26 "allocated and activated". 

The procedures and commands for Data Download via SMS-PP are defined in GSM 11. 14 [27]. 

11.6.13 Menu selection 

Requirement: Service n°27 "allocated and activated". 

The procedures and commands for Menu Selection are defined in GSM 11. 14 [27]. 

11.6.14 Call Control 

Requirement: Service n°28 "allocated and activated". 

The procedures and commands for Call Control are defined in GSM 11.14 [27]. It is mandatory for the ME to perform 
the procedures if it has indicated that it supports Call Control in the TERMINAL PROFILE command. When BDN is 
enabled, the Call control facility of the ME is used by the SIM to support the BDN service. 

11.6.15 Proactive SIM 

Requirement: Service n°29 "allocated and activated". 

The procedures and commands for Proactive SIM, at the application level, are defined in GSM 1 1.14 [27]. 

11.6.16 Mobile Originated Short Message control by SIM 

Requirement: Service n°37 "allocated and activated". 

The procedures and commands for Mobile Originated Short Message control by SIM are defined in GSM 1 1.14 [27]. It 
is mandatory for the ME to perform the procedures if it has indicated that it supports Mobile Originated Short Message 
control by SIM in the TERMINAL PROFILE command. 

11.6.17 SIM data download error 

In case of an ENVELOPE for SIM data download, the SIM can respond with the status words '9E XX' to indicate that 
response data is available. The ME shall use the GET RESPONSE command to get the response data. The ME shall 
then send transparently to the network this response data, using the error procedure of the transport mechanism. 

11.6.18 Image Request 

Requirement: Service n°38 "allocated and activated". 

The ME sends the identification of the information to be read. The ME shall analyse the data of EFjjyfQ (subclause 
10.6.1.1) to identify the files containing the image's instances. If necessary, then the ME performs READ BINARY 
commands on these files to assemble the complete image instance data. 
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Annex A (normative): 
Plug-in SIIVI 



This annex specifies the dimensions of the Plug-in SIM as well as the dimensions and location of the contacts of the 
Plug-in SIM. For further details of the Plug-in SIM see clause 4. 
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NOTE: The Plug-in SIM may be "obtained" by cutting away excessive plastic of an ID-1 SIM. The values in 

parenthesis in figure A.I show the positional relationship between the Plug-in and the ID-1 SIM and are 
for information only. 

Figure A.1 : Plug-in SIM 
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Annex B (normative): 

Coding of Alpha fields in the SIM for UCS2 

If 16 bit UCS2 characters as defined in ISO/IEC 10646 [31] are being used in an alpha field, the coding can take one of 
three forms. If the ME supports UCS2 coding of alpha fields in the SIM, the ME shall support all three coding schemes 
for character sets containing 128 characters or less; for character sets containing more than 128 characters, the ME shall 
at least support the first coding scheme. If the alpha field record contains GSM default alphabet characters only, then 
none of these schemes shall be used in that record. Within a record, only one coding scheme, either GSM default 
alphabet, or one of the three described below, shall be used. 

1) If the first octet in the alpha string is '80', then the remaining octets are 16 bit UCS2 characters, with the more 
significant octet (MSO) of the UCS2 character coded in the lower numbered octet of the alpha field, and the less 
significant octet (LSO) of the UCS2 character is coded in the higher numbered alpha field octet, i.e. octet 2 of the 
alpha field contains the more significant octet (MSO) of the first UCS2 character, and octet 3 of the alpha field 
contains the less significant octet (LSO) of the first UCS2 character (as shown below). Unused octets shall be set 
to 'FF', and if the alpha field is an even number of octets in length, then the last (unusable) octet shall be set to 
'FF'. 

Example 1 



2) 



Octet 1 


Octet 2 


Octet 3 


Octet 4 


Octet 5 


Octet 6 


Octet 7 


Octet 8 


Octet 9 


'80' 


Chi MSO 


Chi LSO 


Ch2Mso 


Ch2Lso 


ChSiviso 


ChSiso 


'FF' 


'FF' 



If the first octet of the alpha string is set to '81', then the second octet contains a value indicating the number of 
characters in the string, and the third octet contains an 8 bit number which defines bits 15 to 8 of a 16 bit base 
pointer, where bit 16 is set to zero, and bits 7 to 1 are also set to zero. These sixteen bits constitute a base pointer 
to a "half-page" in the UCS2 code space, to be used with some or all of the remaining octets in the string. The 
fourth and subsequent octets in the string contain codings as follows; if bit 8 of the octet is set to zero, the 
remaining 7 bits of the octet contain a GSM Default Alphabet character, whereas if bit 8 of the octet is set to one, 
then the remaining seven bits are an offset value added to the 16 bit base pointer defined earlier, and the resultant 
16 bit value is a UCS2 code point, and completely defines a UCS2 character. 

Example 2 



Octet 1 


Octet 2 


Octet 3 


Octet 4 


Octet 5 


Octet 6 


Octet 7 


Octet 8 


Octet 9 


'81' 


'05' 


'13' 


'53' 


'95' 


'A6' 


'XX' 


'FF' 


'FF' 



3) 



In the above example; 

Octet 2 indicates there 5 characters in the string 

Octet 3 indicates bits 15 to 8 of the base pointer, and indicates a bit pattern of Ohhh hhhh hOOO 0000 as the 16 
bit base pointer number. Bengali characters for example start at code position 0980 (0 000 1001 7 000 0000), 
which is indicated by the coding '13' in octet 3 (shown by the italicised digits). 

- Octet 4 indicates GSM Default Alphabet character '53', i.e. "S". 

Octet 5 indicates a UCS2 character offset to the base pointer of '15', expressed in binary as follows 001 0101, 
which, when added to the base pointer value results in a sixteen bit value of 000 1001 1 001 0101, i.e. '0995', 
which is the Bengali letter KA. 

Octet 8 contains the value 'FF', but as the string length is 5, this a valid character in the string, where the bit 
pattern 111 1111 is added to the base pointer, yielding a sixteen bit value of 0000 1001 1111 1111 for the 
UCS2 character (i.e. '09FF'). 

If the first octet of the alpha string is set to '82', then the second octet contains a value indicating the number of 
characters in the string, and the third and fourth octets contain a 16 bit number which defines the complete 16 bit 
base pointer to a "half-page" in the UCS2 code space, for use with some or all of the remaining octets in the 
string. The fifth and subsequent octets in the string contain codings as follows; if bit 8 of the octet is set to zero, 
the remaining 7 bits of the octet contain a GSM Default Alphabet character, whereas if bit 8 of the octet is set to 
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one, the remaining seven bits are an offset value added to the base pointer defined in octets three and four, and 
the resuhant 16 bit value is a UCS2 code point, and defines a UCS2 character. 

Example 3 



Octet 1 


Octet 2 


Octet 3 


Octet 4 


Octet 5 


Octet 6 


Octet 7 


Octet 8 


Octet 9 


'82' 


'05' 


'05' 


'30' 


'2D' 


'82' 


'D3' 


'2D' 


'31' 



In the above example 

Octet 2 indicates there are 5 characters in the string 

Octets 3 and 4 contain a sixteen bit base pointer number of '0530', pointing to the first character of the 
Armenian character set. 

Octet 5 contains a GSM Default Alphabet character of '2D', which is a dash "-". 

Octet 6 contains a value '82', which indicates it is an offset of '02' added to the base pointer, resulting in a 
UCS2 character code of '0532', which represents Armenian character Capital BEN. 

Octet 7 contains a value 'D3', an offset of '53', which when added to the base pointer results in a UCS2 code 
point of '0583', representing Armenian Character small PIWR. 
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Annex C (informative): 
FDN/BDN Procedures 



C "^ ) 



Select DF 



GSM 



Get Response 



Verify CHV1 
(if not disabled) 



Pfiase 1 



.Ph 



PInase 2 



IM N. Phase 2+ 


Perform 


Profile 






V 







ME: unrestricted 

operation , ■-— rr r 

^ (see note1) | 



Select EF 



LOCI 



not invalidated 
(see note 2 




ME: unrestricted 
operation 



(see noteS) 



invalidated 



© 



NOTE 1 : In case of enabled FDN and/or enabled BDN, the EF has been invalidated by the SIIVI at no later than this 

stage. 
NOTE 2: Invalidation of only one of the two EFs is not allowed for FDN and BDN. 
NOTE 3: For SIMs with enabled BDN this procedure is used to check whether the ME supports the Call Control by 

the SIM facility. 

Fig C.I: Example of an Initialization Procedure of a FDN/BDN SIM (see 11.2.1) 
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1 



SIM capability 
request 




yes 



Rehabilitate 



(note 4) 




no 



(note 5) 



yes 



yes 



Rehabilitate 



(note 4) 



-^e 



JEL. 



(note 5) 




restricted or unrestricted 
operation, according to 
the state (enabled/disabled) 
of the various services 
(FDN,CC) 



no operation FDN operation 



NOTE 4: In case of "BDN enabled", the SIM only allows rehabilitation of the EFmsi and EFloci, if the ME has 
indicated its CC-capability to the SIM (by PROFILE_DOWNLOAD). 



NOTE 5: Possibility for future "restricting" services to use the internal SIM mechanism of invalidation of EFimsi 
and EFloci- 



NOTE 6: If the ME does not support all enabled services (e.g. FDN, BDN), it does not operate. In case of enabled 
BDN, the support of the "Call Control Feature" by the ME is sufficient for operation. For future use, there 
may be additional "restricting" services, which are not known to the ME. In that case the ME will perform 
the subsequent rehabilitation procedure but will fail to rehabilitate EFimsi and EFloci (see note 4). 

Figure C.1 : Example of an Initialization Procedure of a FDN/BDN SIM (continued) 



£75/ 



(GSM 11.11 version 7.3.0 Release 1998) 



115 



ETSI TS 100 977 V7.3.0 (1999-07) 



BDN capability 
request 



FDN capability 
request 



Figure C.2: SIM capability request 



no 



Select EF ggj 



Read EFsst 



yes 



Select DFjELECor 



Select EF bdn 



Get Response 

(evaluation of 

invalidation flag) 



BDN enabled 




yes 




no 



BDN disabled 



No BDN Sll\/I 



Figure C.3: BDN capability request (see 11.5.1) 
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no 



Select EF 



SST 



Read EF 



SST 



(see note 7) 



yes 




Get Response 
(evaluation of 
invalidation flag) 




FDN enabled 



FDN disabled No FDN SIIUI 



NOTE 7: In this case FDN is enabled without the possibility of disabling. 

Figure C.4: FDN capability request (see 11.5.1) 
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a Rehabilitate [N 



Select EF 



IMSI 



Rehabilitate 



EF 



IMSI 



Select EF 



LOCI 



Rehabilitate 

^^ LOCI 



I 



(Note 8) 



(Note 8) 



NOTE 8: If BDN is enabled in the SIM, and if the Profile download procedure has not indicated that the ME 
supports Call Control, the EF is not rehabilitated by the SIM. 

Figure C.5: Procedure to rehabilitate GSIUI files 




FDN enabled 



Boolean Equation: 

FD = FDA.(NOT(ADA+ADA.ADI) 

where 
FD = FDN enabled 
FDA = FDN allocated and activated 
ADA = ADN allocated and activated 
AD I = EF ADN invalidated 



FDN not enabledl enabled 
Figure C.6: Coding for state of FDN 
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Annex D (informative): 

Suggested contents of the EFs at pre-personalization 

If EFs have an unassigned value, it may not be clear from the main text what this value should be. This annex suggests 
values in these cases. 



File Identification 


Description 


Value 


'2F E2' 


ICC identification 


operator dependant (see 10.1.1) 


'2F 05' 


Extended Language preference 


'FF...FF' 


'6F 05' 


Language preference 


'FF' 


'6F 07' 


IIVISI 


operator dependant (see 10.3.2) 


■6F 20' 


Ciphering key Kc 


'FF...FF07' 


'6F 30' 


PLMN selector 


'FF...FF' 


'6F31' 


HPLMN search period 


'FF' 


'6F 37' 


ACM maximum value 


'000000' (see note 1 ) 


■6F 38' 


Sll\/I service table 


operator dependant (see 10.3.7) 


'6F 39' 


Accumulated call meter 


'000000' 


'6F3E' 


Group identifier level 1 


operator dependant 


'6F3F' 


Group identifier level 2 


operator dependant 


'6F41' 


PUCT 


'FFFFFFOOOO' 


'6F 45' 


CBMI 


'FF...FF' 


'6F 46' 


Service provider name 


'FF...FF' 


'6F 48' 


CBMID 


'FF...FF' 


'6F 49' 


Service Dialling Numbers 


'FF...FF' 


'6F 74' 


BCCH 


'FF...FF' 


'6F 78' 


Access control class 


operator dependant (see 10.1.12) 


'6F 7B' 


Forbidden PLMNs 


'FF...FF' 


'6F7E 


Location information 


'FFFFFFFF xxFxxx 0000 FF 01 ' 
(see note 2) 


'6F AD' 


Administrative data 


operator dependant (see 10.3.15) 


'6FAE' 


Phase identification 


see 10.3.16 


'6F 3A' 


Abbreviated dialling numbers 


'FF...FF' 


'6F 3B' 


Fixed dialling numbers 


'FF...FF' 


'6F 3C' 


Short messages 


'OOFF...FF' 


'6F3D' 


Capability configuration parameters 


'FF...FF' 


'6F 40' 


MSISDN storage 


'FF...FF' 


'6F 42' 


SMS parameters 


'FF...FF' 


■6F 43' 


SMS status 


'FF...FF' 


'6F 44' 


Last number dialled 


'FF...FF' 


'6F 47' 


Short message status reports 


'OOFF...FF' 


'6F 4A' 


Extension 1 


'FF...FF' 


'6F 4B' 


Extension 2 


'FF...FF' 


'6F 4C' 


Extension 3 


'FF...FF' 


'6F4D' 


Barred dialling numbers 


'FF...FF' 


'6F4E' 


Extension 4 


'FF...FF' 


'6F51' 


Network's indication of alerting 


'FF...FF' 


'6F 52' 


GPRS Ciphering key KcGPRS 


'FF...FF07' 


'6F 53' 


GPRS Location Information 


'FFFFFFFF FFFFFF xxFxxx 0000 FF 01' 


'6F 54' 


SetUpMenu Elements 


operator dependant (see 10.3.34) 


'4F 20' 


Image data 


'OOFF...FF' 


'4F 30' 


SoLSA Access Indicator) 


'OOFF...FF' 


'4F31' 


SoLSA LSA List 


'FF...FF' 



NOTE 1: The value '000000' means that ACMmax is not valid, i.e. there is no restriction on the ACM. When 

assigning a value to ACMmax, care should be taken not to use values too close to the maximum possible 
value 'FFFFFF', because the INCREASE command does not update EF^(-^[^ if the units to be added would 
exceed 'FFFFFF'. This could affect the call termination procedure of the Advice of Charge function. 

NOTE 2: xxFxxx stands for any valid MCC and MNC, coded according to GSM 04.08 [15]. 
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Annex E (informative): 

SIIVI application Toolkit protocol diagrams 

The diagrams in this annex are intended to illustrate the data protocols of the SIM toolkit application in various 
situations. The SIM application is shown as initiated by SMS Data Download messages. Other possibilities exist (as 
defined in GSM 11. 14) such as data entry fi^om a menu selection. 



Case 1: Simple 



Network 



ME 



GSM 
SIM 



SIM 
Application 



SMSsiM 

_Data_Download/Class_2 


ENV(SMS) 






'9000' 


SMS Ack 







(SMS) 



'9000') 



This shows the simple case where an SMS for SIM updating is received from the network, passed to the SIM by the ME 
and processed immediately by the SIM application. This requires no ME action except to acknowledge the SMS. 
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Case 2: Simple with short delay 



Network 



ME 



GSM 
SIM 



SIM 
AppI 



SMSsiM 

_Uata_Uownload/Class_2 



SMS Ack 



ENV(SMS) 


(SMS) 


'60' 


('60') 


'60' 


('60') 


'9000' 


('9000') 







This shows the simple case where an SMS for SIM updating is received from the network, passed to the SIM by the ME 
and which requires some time to process by the SIM application. The processing time is "not long" and is obtained by 
the SIM application sending "null procedure bytes" to the ME. Each byte has the effect of restarting the work waiting 
time so that the ME does not abort the transaction before the SIM application has finished processing the command(s) 
sent in the SMS. 



Guidelines on timings: 

1. The SMS Ack must be sent back before the network times out and sends the SMS again. 

2. Use of null procedure bytes must not be excessive as during this time the ME is unable to issue normal GSM 
commands to the SIM. 



£75/ 



(GSM 11.11 version 7.3.0 Release 1998) 



121 



ETSI TS 100 977 V7.3.0 (1999-07) 



Case 3: Simple with short delay and SIM Acknowledgement 



Network 



ME 



GSM 
SIM 



SIM 
AppI 



SMSsiM 


ENV(SMS) 


(SMS) 


_Data_Download/C1ass_2 




'60' 




('60') 




'60' 


('60') 




'9F10' 


('9F10') 




(SIM Ack) 




Get Response (16 bytes) 




SIM Ack 






SMS Ack (with 
SIM Ack) 







This shows the same case as previously where an SMS for SIM updating is received from the network, passed to the 
SIM by the ME and which requires some time to process by the SIM application. However in this case the SIM 
application has SIM acknowledgement data to include in the SMS acknowledgement being returned to the network by 
the ME. 



Guideline on timings: 

The SMS Ack must be sent back before the network times out and sends the SMS again. 
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Case 4: A Toolkit command generated by the SIM application as a result of an SMS from the network 



Network 



ME 



GSM 
SIM 



SIM 
Application 



SMSsiM 


ENV(SMS) 


(SMS) 


_Data_Download/Class_2 




'60' 


('60') 




'60' 


('60') 




'91XX' 


('91XX') 




(FETCH) 


SMS Ack 


FETCH 






Command 




(Command) 




(TERMINAL RESPONSE) 




TERMINAL RESPONSE 




'9000' 




('9000') 











This shows the case where an SMS for SIM updating is received from the network, passed to the SIM by the ME and 
processed by the SIM application which then generates a command for action by the ME (e.g. PLAYTONE). 

NOTE: If a positive acknowledgement to the network of completion of execution of the instructions given in the 
SMS message is required then the SIM application can issue a command to the ME to send a MO SMS. 
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Case 5: A normal GSM command requires processing before the ME can respond to the 91XX from the SIM 



Network 



ME 



GSM 
SIM 



SIM 
Application 



SMSs 



_Data_Download/Class_2 



SMS Ack 



ENV(SMS) 



'91XX' 



GSM Command 



'91XX' 



FETCH 



Command 



TERMINAL RESPONSE 



'9000' 



(SMS) 



('91XX') 



(FETCH) 



(Command) 



(TERMINAL RESPONSE) 



('9000' 



This shows the case where an SMS for SIM updating is received from the network, passed to the SIM by the ME and 
processed by the SIM application which then generates a command for action by the ME (e.g. PLAYTONE). However a 
normal GSM command requires processing before the ME can FETCH the command which the SIM is waiting to give 
it. The response to the normal GSM command is '91XX' in this case to remind the ME of the outstanding SIM 
application command request. 
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Case 6: MORE TIME Command 



Network 



ME 



GSM 
SIM 



SIM 
Application 



SMSsiM 


ENV(SMS) 


(SMS) , 


_Data_Download/Class_2 




'91XX' 




\ ~J 


SMS Ack 


('91XX') 

(FETCH) 
(MORETIME) 

(TERMINAL RESPONSE) . 




FETCH 








MORETIME 






TERMINAL RESPONSE 






'9000' 




\ \ 




('9000') 











This shows the case where an SMS for SIM updating is received from the network, passed to the SIM by the ME and 
requires a considerable period of time to be processed by the SIM application. In this case the use of null procedure 
bytes only is inappropriate as the ME must be given the opportunity to process normal GSM commands. The 
opportunities gained by the SIM application for processing, and the opportunities for normal GSM commands are shown 
in the diagram above. The sequence of 91XX, FETCH and MORETIME commands can be repeated if required. 



Opportunities to process normal GSM commands are shown thus: 



Opportunities for SIM application processing are shown thus: 
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Case 7: SIM Application Busy 



Network 



ME 



GSM 
SIM 



SIM 
Application 



SMSs 



_Data_Download/Class_2 



SMS NACK 





While the SIM application is busy processing a SMS for the SIM application arrives from the network and is sent to the 
SIM by the ME in the usual manner. The SIM operating system recognizes that the SIM application is busy, and it sends 
a busy response ('9300') to the ME. The ME then sends negative acknowledgement to the network. The responsibility 
for a retry rests with the network. 
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Annex F (informative): 

Examples of coding of LSA Descriptor files for SoLSA 

The length of all the records is determined by the LSA descriptor containing the largest number of bytes. Combinations 
containing different numbers of LSA IDs, LAC+ CI and CI or LAC can therefore be done. Various examples are show. 
Due to the OTA management of the records it is recommended that the record length is maximum 100 bytes in order to 
leave room for command descriptor and signature information in the SMS. 

This first example contains two LSAs, one described by two LSA IDs and another described by three Cell IDs, giving a 
record length of 8 bytes. 



1^' record: 


LSA descriptor 
type = LSA ID 
and number = 2 
(1 byte) 


LSA ID (3 bytes) 


LSA ID (3 bytes) 


Identifier (1 byte) 
















2"^* record: 


LSA descriptor 
type = CI and 
number = 3 
(1 byte) 


CI (2 bytes) 


CI (2 bytes) 


CI (2 bytes) 


Identifier (1 byte) 



The second example contains two LSAs, one described by one LSA ID and one described by two Cell Ids, giving a 
record length of 6 bytes. 



1^ record: 


LSA descriptor 
type = LSA ID 
and number = 1 
(1 byte) 


LSA ID (3 bytes) 


'FF' 


Identifier (1 byte) 












2"" record: 


LSA descriptor 
type = CI and 
number = 2 
(1 byte) 


CI (2 bytes) 


CI (2 bytes) 


Identifier (1 byte) 



£75/ 



(GSM 11.11 version 7.3.0 Release 1998) 



127 



ETSI TS 100 977 V7.3.0 (1999-07) 



Annex G (normative): 
Image Coding Schemes 



The following image coding schemes are applicable to rectangular raster images. Raster image points are assumed to be 
of square shape. They are numbered sequentially from 1 onwards, starting at the upper left corner, proceeding line by 
line downwards, each line in turn proceeding from left to right, and ending at the image's lower right corner. 

The following example illustrates the numbering scheme for raster image points by showing how the corner points are 
numbered, assuming an image length of x points and an image height of y points. 



1 



(xMy-i) + i) 



(x'y) 



G.1 Basic Image Coding Scheme 

This coding scheme applies to rectangular raster images made up of raster points that are either set or not set. This 
coding scheme does not support any notion of colour. Image data are coded as follows: 



Byte(s) 


Description 


Length 


1 


image width = X 


1 


2 


image height = Y 


1 


3 to K+2 


image body 


K 



Coding of image body: 

The status of each raster image point is coded in one bit, to indicate whether the point is set (status = 
(status = 0). 

Byte 1: 



1) or not set 



b7 b6 b5 b4 b3 b2 bl 



status of 

status of 

status of 

status of 

status of 

status of 

status of 

status of 



raster point 8 
raster point 7 
raster point 6 
raster point 5 
raster point 4 
raster point 3 
raster point 2 
raster point 1 



Byte 2: 



b7 b6 b5 b4 b3 b2 bl 



status of 

status of 

status of 

status of 

status of 

status of 

status of 

status of 



raster point 16 
raster point 15 
raster point 14 
raster point 13 
raster point 12 
raster point 11 
raster point 10 
raster point 9 



etc. 



Unused bits shall be set to 1 
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G.2 Colour Image Coding Scheme 

This coding scheme appHes to coloured rectangular raster images. Raster image point colours are defined as references 
into a colour look-up table (CLUT), which contains a subset of the red-green-blue colour space. The CLUT in turn is 
located in the same transparent file as the image instance data themselves, at an offset defined within the image instance 
data. 

Image data are coded as follows: 



Byte(s) 


Description 


Length 


1 


Image width = X 


1 


2 


Image height = Y 


1 


3 


Bits per raster image point = B 


1 


4 


Number of CLUT entries = C 


1 


5 to 6 


Location of CLUT (Colour Look-up Table) 


2 


7 to K+6 


Image body 


K 



■ Bits per raster image point: 

Contents: 

The number B of bits used to encode references into the CLUT, thus defining a raster image point's 

colour. 

B shall have a value between 1 and 8. 
Coding: 

Binary. 

■ Number of entries in CLUT: 

Contents: 

The number C of entries in the CLUT which may be referenced from inside the image body. CLUT 

entries are numbered from to C-L 

C shall have a value between 1 and 2**B. 
Coding: 

Binary. The value shall be interpreted as 256. 

■ Location of CLUT: 

Contents: 

This item specifies where the CLUT for this image instance may be found. The CLUT is always 
located in the same transparent file as the image instance data themselves, at an offset determined by 
these two bytes. 



Coding: 



Byte 1 : high byte of offset into Image Instance File. 
Byte 2: low byte of offset into Image Instance File. 



Image body: 

Coding: 



Each raster image point uses B bits to reference one of the C CLUT entries for this image instance. 
The CLUT entry being thus referenced yields the raster image point's colour. 
The image body is arrayed as for the Basic Colour Image Coding Scheme, that is, starting with the 
highest bit of the first raster image point's colour information. 



Byte I: 



b7 b6 b5 b4 b3 b2 bl 



. . . etc 

. . . etc 

. . . etc 

. . . etc 

. . . etc 

Bit B-2 of raster point 1 CLUT reference 

Bit B-1 of raster point 1 CLUT reference 

Bit B (MSB) of raster point 1 CLUT reference 



etc. 

Unused bits shall be set to 1 . 
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The CLUT (Colour Look-up Table) for an image instance with C colours is defined as follows: 
Contents: 

C CLUT entries defining one colour each. 
Coding: 

The C CLUT entries are arranged sequentially: 



Byte(s) of CLUT 


CLUT Entry 


1-3 


entry 






3*(C-1)+1 to3*C 


Entry C-1 



Each CLUT entry in turn comprises 3 bytes defining one colour in the red-green-blue colour space: 



Byte(s) of CLUT enty 


Intensity of Colour 


1 


Red 


2 


Green 


3 


Blue 



A value of 'FF' means maximum intensity, so the definition 'FF' '00' 00' stands for fully saturated red. 

NOTES: 

- Two or more image instances located in the same file can share a single CLUT. 

- Most MEs capable of displaying colour images are likely to support at least a basic palette of red, green, blue 
and white. 
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Annex H (informative): 

EF changes via Data Download or SIIVI Toolkit applications 

This annex defines if changing the content of an EF by the network (e.g. by sending an SMS), or by SIM Toolkit 
AppHcation (e.g. by using the SIM API), is advisable. Updating of certain EFs, "over the air" such as EFacc could result 
in unpredictable behaviour of the MS; these are marked "Caution" in the table below. Certain EFs are marked "No"; 
under no circumstances should "over the air" changes of these EFs be considered. 



File identification 


Description 


Change advised 


'2F 05' 


Extended Language preference 


Yes 


'2F E2' 


ICC identification 


No 


'4F 20' 


Image data 


Yes 


'4F XX' 


Image Instance data Files 


Yes 


'6F 05' 


Language preference 


Yes 


'6F 07' 


IMSI 


Caution (Note 1 ) 


'6F 20' 


Ciphering key Kc 


No 


'6F 2C' 


De-personalization Control Keys 


Caution 


'6F 30' 


PLMN selector 


Caution 


'6F31' 


HPLMN search period 


Caution 


'6F 32' 


Co-operative network 


Caution 


'6F 37' 


ACM maximum value 


Yes 


'6F 38' 


SIM service table 


Caution 


'6F 39' 


Accumulated call meter 


Yes 


'6F 3A' 


Abbreviated dialling numbers 


Yes 


'6F 3B' 


Fixed dialling numbers 


Yes 


'6F 3C' 


Short messages 


Yes 


'6F 3D' 


Capability configuration parameters 


Yes 


'6F3E' 


Group identifier level 1 


Yes 


'6F3F' 


Group identifier level 2 


Yes 


'6F 40' 


MSISDN storage 


Yes 


'6F41' 


PUCT 


Yes 


'6F 42' 


SMS parameters 


Yes 


'6F 43' 


SMS status 


Yes 


'6F 44' 


Last number dialled 


Yes 


'6F 45' 


CBMI 


Caution 


'6F 46' 


Service provider name 


Yes 


'6F 47' 


Short message status reports 


Yes 


'6F 48' 


CBMID 


Yes 


'6F 49' 


Service Dialling Numbers 


Yes 


'6F 4A' 


Extension 1 


Yes 


'6F 4B' 


Extension 2 


Yes 


'6F 4C' 


Extension 3 


Yes 


'6F 4D' 


Barred dialling numbers 


Yes 


'6F4E' 


Extension 4 


Yes 


'6F 50' 


CBMIR 


Yes 


'6F51' 


Network's indication of alerting 


Caution 


'6F 52' 


GPRS Ciphering key KcGPRS 


No 


'6F 53' 


GPRS Location Information 


Caution 


'6F 74' 


BCCH 


No 


'6F 78' 


Access control class 


Caution 


'6F 7B' 


Forbidden PLMNs 


Caution 


'6F 7E' 


Location information 


No (Note 1) 


'6FAD' 


Administrative data 


Caution 


'6FAE' 


Phase identification 


Caution 


'6FB1' 


Voice Group Call Service 


Yes 


'6F B2' 


Voice Group Call Service Status 


Yes 


'6F B3' 


Voice Broadcast Service 


Yes 


'6F B4' 


Voice Broadcast Service Status 


Yes 


'6F B5' 


Enhanced Multi Level Pre-emption and Priority 


Yes 


'6F B6' 


Automatic Answer for eMLPP Service 


Yes 


'6F B7' 


Emergency Call Codes 


Caution 


N0TE1 : If EFiMsi is changed, the SIM should issue REFRESH as defined in GSM 1 1 .14 [27] and update 
EFloci accordingly. 
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Annex I (informative): 
Change history 



This annex lists all change requests approved for the present document since the first phase2+ version was approved by 
ETSI SMG. 



SMG# 


SMG 
tdoc 


SMG9 
tdoc 


VERS 


CR 


RV 


PH 


CAT 


SUBJECT 


Resulting 
Version 


s16 


709/95 


154/95 


4.15.0 


A008 




R96 


1 


SIM Speed Enhancement 


5.0.0 


s17 


062/96 


147/95 


5.0.0 


A006 




R96 


B 


Service Dialling Numbers 


5.1.0 


060/96 


06/96 


A009 




R96 


B 


ASCI for VGCS and VBS 


060/96 


06/96 


A010 




R96 


B 


ASCI for eMLPP 


059/96 


204/95r 


A013 




R96 


C 


Interaction between FDNs and ADNs 


061/96 


05/96 


A014 




R96 


D 


Correction of baud rate for SIM Speed enhancement 


s18 


263/96 


57/96 


5.1.0 


A011 


3 


R96 


B 


SIM Application Toolkit protocol enhancements 


5.2.0 


260/96 


45/96 


A016 




R96 


A 


SIM presence detection clarification 


261/96 


54/96 


A018 




R96 


A 


Reponse codes and coding of SIM service table 


262/96 


55/96 


A020 




R96 


A 


Reference to International Standards 


s19 


374/96 


102/96 


5.2.0 


A012 




R96 


C 


Contacting elements 


5.3.0 


373/96 


105/96 


A023 




R96 


A 


Clarification of clock stop timing 


409/96 


107/96 


A024 


1 


R96 


B 


Emergency Call Codes (ECC) 


374/96 


108/96 


A025 




R96 


C 


Using ranges of CBMIs 


s20 


580/96 


206/96 


5.3.0 


A021 




R96 


B 


Barred Dialling Numbers 


5.4.0 


734/96 


197/96 


A026 




R96 


B 


Addition of Cooperative Network List EF 


734/96 


197/96 


A027 




R96 


B 


Addition of ME Depersonalisation feature and EF 


702/96 


207/96 


A031 




R96 


D 


RFU bit taken into use in GSM 11.12 


s21 


101/97 


97/079 


5.4.0 


A032 


2 


R96 


D 


Ammendment to BDN diagrams in Annex B 


5.5.0 


101/97 


97/086 


A033 


1 


R96 


B 


DFs for MSS/ PCS1 900/other use 


101/97 


97/056 


A034 




R96 


C 


Reading of EFDCK during SIM initialisation 


101/97 


97/058 


A036 




R96 


D 


Administrative Access Conditions 


101/97 


97/059 


A037 




R96 


B 


Format of EFCNL to include fields for Corporate Personal. Code 


101/97 


97/089 


A041 




R96 


B 


Administrative Data field 


s22 


356/97 


183/97 


5.5.0 


A042 




R97 


B 


Extended language preference 


5.6.0 


356/97 


163/97 


A044 


1 


R96 


A 


Clarification of electrical/mechanical SIM/ME interface 


356/97 


179/97 


A045 




R96 


D 


Security procedures for 2nd level; DFs located under DF GSM 


356/97 


187/97 


A047 




R96 


F 


Number of bytes returned after a SELECT command 


356/97 


093/97 


A048 




R96 


D 


Serivce table and "radio interface" 


356/97 


109/97 


A049 




R96 


F 


Update Access condition of EFDCK (aligns 11.11 & 02.22) 


s23 


788/97 


97/249 


5.6.0 


A046 


2 


R97 


B 


Short Message Status Reports 


5.7.0 


788/97 


97/243 


A050 




R96 


F 


Addition of SDN and BDN in the description of EFCCP 


788/97 


97/259 


A051 


1 


R97 


C 


SIM and ME behaviour when SIM is disabled and blocked 


788/97 


97/262 


A053 




R96 


F 


Response data following an ENVELOPE command 


788/97 


97/260 


A054 




R96 


F 


Coding of EFPhase 


788/97 


97/271 


A055 




R97 


C 


Changes to Dialling Number Files and extensions 


788/97 


97/261 


A056 




R97 


B 


Network's indication of alerting in the MS 


s24 


97-0886 


97/365 


5.7.0 


A052 


2 


R97 


b 


Introduction of UCS2 


5.8.0 


97-0886 


97/383 


A057 




R97 


c 


MO SMS control by SIM 


At SMG #25, it was decided to create a version 6.0.0 of every specification that contained at least one release '97 work item and a 
version 7.0.0 of every specification that contained at least one release '98 work item. 


s25 


98-0157 


98p052 


5.8.0 


A058 


2 


R97 


B 


Addition of EFs for GPRS 


6.0.0 


98-0157 


98p108 


A059 




R97 


F 


Clarification regarding EFCCP records 


98-0157 


98p094 


A061 


1 


R96 


A 


Clarification of removal of the SIM 


s26 


98-0398 


98p228 


6.0.0 


A062 


2 


R98 


B 


Icons - addition of EF IMG and DF GRAPHICS 


7.0.0 


98-0398 


98p227 


A064 




R98 


B 


Operation of ME with multiple card readers 


98-0400 


98p237 


A065 




R98 


F 


Deletion of all release 97 markers from the R98 version 


98-0398 


98p240 


A066 




R97 


F 


RP-ACK RP-ERROR for SIM data download error 


98-0398 


98p263 


A069 




R97 


D 


Allocation of file ID for IS-41 














(continued) 
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Change History (continued) 



SMG# 


SMG 
tdoc 


SMG9 
tdoc 


VERS 


CR 


RV 


PH 


CAT 


SUBJECT 


Resulting 
Version 


s27 


98-0671 


98p339 


7.0.0 


A071 




R98 


c 


Enhanced image coding schemes (colour icons) 


7.1.0 


98-0671 




A072 


1 


R98 


D 


Addition of reference to PCS 1900 


s28 


P-99-185 


9-99-076 


7.1.0 


A073 


1 


R98 


F 


Alignment with 2™ edition of ISO/IEC 7816-3 (1997) 


7.2.0 


P-99-185 


9-99-037 


A074 




R98 


B 


Addition of SoLSA data fields 


P-99-185 


9-99-066 


A075 


1 


R98 


B 


Addition of CIS fields 


P-99-185 


9-99-095 


A076 


1 


R98 


B 


Definition of a file containing the title of the main menu 


P-99-185 


9-99-072 


A077 




R98 


C 


USSD format indication in the SIM Service Table 


P-99-185 


0-99-093 


A078 




R98 


B 


Informative annex on EF changes 


P-99-185 


9-99-097 


A080 




R98 


C 


Additional GPRS field 


P-99-188 




A082 




R98 


D 


Deletion of $( )$ release markers 


s29 


P-99-412 


9-99-163 


7.2.0 


A083 


1 


R98 


C 


EF IMSI changes via data download or SIM toolkit application 


7.3.0 


P-99-412 


9-99-180 


A084 




R98 


F 


Addition of RUN AT COMMAND to the SIM service table 
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